Domain win.psu.edu Authentication Changes

Summary

ASET removed the password change synchronization from www.work.psu.edu to the win.psu.edu domain on August 15, 2006. The win.psu.edu domain now uses the MIT Kerberos servers in the dce.psu.edu realm and a "cross-realm trust" for password authentication. Users logging onto computers in the win.psu.edu tree who were using accounts in win.psu.edu have to log into the dce.psu.edu Kerberos realm instead of win.psu.edu. Shadow accounts will still be maintained in win.psu.edu and Kerberos name mappings have been set to enable this. After logging in users have credentials for both win.psu.edu and dce.psu.edu, so this may be viewed as an expanded service. ACLs on file servers for principals in win.psu.edu do not have to be changed, but any service relying on NTLM and not Kerberos no longer works.

Schedule

9/1/05 — Have trust from win.psu.edu to dce.psu.edu working
10/1/05 — Begin testing with lab computers in labs.win.psu.edu
12/15/05 — Set Kerberos name mappings for all shadow accounts in win.psu.edu
3/24/06 — Make MSI available to define registry entries for the Kerberos servers in dce.psu.edu: \\jaws2.win.psu.edu\GGPO\DceKDCs.msi
4/17/06 — Announce testing for rovers and lab consultants for computers in labs.win.psu.edu
6/xx/06 — Testing
7/5/06 — PSU Gina stops working (not really related to this change, but should happen before passwords are de-sync'ed).
8/15/06 — ASET turns password sync off on www.work.psu.edu.
8/21/06 — Randomized user passwords in win.psu.edu

Details

Logging onto a computer in the win.psu.edu forest using the dce.psu.edu Kerberos realm results in credentials for win.psu.edu, as long as there is no name mapping for a matching user account the child domain. In other words, do not set Kerberos name mappings for accounts in the child domain (such as staff.win.psu.edu).

The registry settings set by the "DceKDCs.msi" are in the key SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains\dce.psu.edu.

The RealmFlags value is a REG_DWORD 8. A multreg value named KdcNames previously documented here is no longer needed.

You can find a reg file in this zip file.

For the labs.win.psu.edu domain we will also deploy an MSI that sets/resets the default login domain to dce.psu.edu so that if someone picks win the next person will see dce.psu.edu. We'll discuss if that should be linked for the staff domain or OU's in the staff domain.

Testing

Password de-sync, re-sync

Testing with your win.psu.edu password synchronized with your dce.psu.edu is not indicative of what will work or not. Windows will often use cached passwords from other domains when attempting to access resources. You might first try logging into dce.psu.edu without changing your win.psu.edu password to see if everything works the same way, but then you should change the win.psu.edu password and try again.

Go to https://clc.its.psu.edu/DomPassChange.aspx to change your win.psu.edu domain password to something else, then test logging onto dce.psu.edu with your Access Account password, NOT the one you just set.

If you forget what your new win.psu.edu password is, you can go to https://clc.its.psu.edu/SetWinPass.aspx to set it back to the same as your dce.psu.edu password. We may have to keep this utility after August 1 in case of unforeseen problems (it has been removed).

Verify both passwords at https://clc.its.psu.edu/users/VerifyPassword.aspx. This page will also tell you if you win.psu.edu account is locked.

What To Test, Staff

The goal is that everything should look the same and work the same when logging on with dce.psu.edu\<userid> instead of win.psu.edu\<userid>. If the account has been used in CLC labs and the profile set to roaming on the workstation, you may even see the U: and V: drives connected automatically.

You can connect to a share like \\dc1.aset.psu.edu\sysvol to see if you have credentials for it. You should not be prompted for a userid and password when logged into dce.psu.edu.

What To Test, Labs

Lab consultants can test on (selected?) consultant machines:

On login screen, pick "dce.psu.edu (Kerberos Realm)" from domain drop-down list.
Log on.
Go to https://clc.its.psu.edu/DomPassChange.aspx and change your win.psu.edu domain password.
Log off, note that the default domain changed back to WIN. Pick "dce.psu.edu (Kerberos Realm)" again from the domain drop-down list. Log on with your OLD (Access Account) password.
Everything should work the same. You should not be prompted for a userid/password for accessing things that you were able to connect before (except \\UBackup\Users; connect to \\Beast\Users to use your Kerberos credentials).
Go to https://clc.its.psu.edu/DomPassChange.aspx or https://clc.its.psu.edu/SetWinPass.aspx to change your WIN password back to match your Access Account password.

Wireless

Computers with wireless-only connections may be a problem. Need to test.

Profiles

Roaming profiles seem ok. However, if you get an error message with an event log description like "Cross Forest roaming user profiles are disabled. Windows did not load your roaming profile and is logging you on with a local profile. Changes to the profile will not be copied to the server when you logoff. Contact your network administrator." you have to enable the policy "Allow Cross-Forest User Policy and Roaming User Profiles", found under Administrative Templates, System/Group Policy. (Shouldn't this be set domain-wide? Checking.)

Local profiles should be tested (same or different?)

Informational Tools

The Windows Resource Kit has a klist.exe that will list your current Kerberos tickets, and a krbtray.exe that will put an icon in the notification area that you can click on to open a window to list Kerberos tickets. You may have to be a power user or administrator for those to work. To add an account to the local administrators group, you would add win\<userid>, not dce.psu.edu\<userid>.

Problems

Send new problem reports to admin@staff.win.psu.edu.

Known Problems

Assuming the WIN account password is not the same as the dce.psu.edu Kerberos password, there these known problems:

Server Name. You cannot connect to a file server using a CNAME or a DNS name in a zone that is not the Windows domain; you have the use the real Windows name. For example, a share Public on a server webtest.win.psu.edu can be connected to as \\webtest.win.psu.edu\public, or \\webest\public (if win.psu.edu is a DNS domain suffix defined for TCP/IP on that computer), but if the server is also registered in DNS as webtest.tlt.psu.edu, you will be prompted for a userid and password and you will not be able to connect.
Kerberos names can be defined for cluster resources.
- Thus, connecting to a share like \\ubackup.win.psu.edu\users used to fail with the dce.psu.edu password. We installed cluster server and made a one node cluster on that server in order to virtualize the server name (which enables it for Kerberos).
GPO's not applied http://support.microsoft.com/default.aspx/kb/892090; we think we didn't have this problem in labs.win.psu.edu because we have loopback policy processing for computers (Computer policies apply to user policies).
Roaming Profiles: need policy "Allow Cross-Forest User Policy and Roaming User Profiles"
Connecting to resources from outside the Penn State network via a VPN Connection:
- OS X -- doesn't work
- Windows XP -- sometimes doesn't work

Unknowns Problems

Management requests a list of all unknown problems. Please forward your unknown problems up your management chain.

Solved Problems

Locked or Disabled accounts: If an application or subsystem uses NTLM instead of Kerberos, the win.psu.edu account may get locked for invalid password attempts. When logging on you may get a message saying that your account is locked or disabled. We are seeing accounts getting locked out and we don't know why. The problem is being investigated. Some notes:
- The win domain account lockout policies are:
  - Account lockout duration: 30 5 (changed on 6/30) minutes
  - Account lockout threshold: 40 invalid logon attempts
  - Reset account lockout couner after: 30 5 (changed on 6/30) minutes
- If an account gets locked out, you can wait 5 minutes or email admin@staff.win.psu.edu and someone will unlock the account. Changing your password does not unlock your account. We may have to suspend the locking policy or build a self-service web page to unlock accounts if this is a continuing problem.
With the default login domain set to dce.psu.edu on 6/20, and www.work failing to set the WIN password sometimes, more users are getting locked out. We think this is because they haven't logged into a lab machine in several weeks and their roaming profile has a setting for a persistent connection to the UDrive using their WIN\Userid account (or restoring a connection defaults to using the WIN\Userid account or NTLM). On 6/29 UserSetup was changed to always delete the V: and U: drives and then try to connect using dce.psu.edu\Userid.
Later we find the current version of our MapPrinter program did not get deployed; the old one was using CNames.
IIS, Basic Auth, Integrated Security for SQL Connection: Web apps that depend on integrated security to connect to SQL do not work when passwords are not synchronzied between dce.psu.edu and win.psu.edu.
- Fixed 7/3/06, bxk
- Need to set RealmFlags dword registry value to 4.
- The prescribed value of 8 cannot be combined (12 doesn't work). Looks like valid values are 0 to 7.
- Bxk found 0 works ok too; the TGT's are "forwardable".
- We will ask MS what the article at http://technet2.microsoft.com/WindowsServer/en/Library/052a26e5-8c1b-4ec8-9ecd-a15b047ccf661033.mspx?mfr=true says.
cjs, test accounts locked, staff computer: turned out to be weird thing with FSMonitor job on FPS-Willard which uses that test account to connect to win.pass.psu.edu.
cjs, test accounts locked, lab computer: was wrong GPO link resulting in old config for MapPrinters.exe.
jrh, could not load profile; setting policy "Allow Cross-Forest User Policy and Roaming User Profiles" fixed that; odd since other test lab computers didn't have the problem and so far staff computers don't either.
4/24/06: Cluster server installed on Beast to kerberize name ubackup.win.psu.edu.
7/1/06: Fix account lockouts by redeploying fixed MapPrinters app (that doesn't use cnames).

© 2006, The Pennsylvania State University. All rights reserved.
This site maintained by the Classroom and Lab Computing group of Information Technology Services.
Suggestions and comments about this web site: CLC Webmasters; Other contacts here.

This page was last modified: 1/23/2007 9:11:59 AM.