Unity Migration Blog

We recreated all of the Unity AD accounts on 5/17/2006. The accounts were given random passwords when they were created. The accounts created on this date which have not used the reset password web page have had their passwords reset to the default Unity password combination this morning.

Any user who has used the password reset web page after 5/17/2006 has a synchronized AD password.

Any user account generated after 5/17/2006 has a synchronized AD password becuase the default Unity password combination is used when the accounts are generated.

This means that all Unity AD passwords should be known to the user. The password will either be determined by the user via the password reset web page or will be the default Unity combination.

Here are some statistics:

By looking at the pwdLastSet attribute on AD user entries, you can tell when the password was last set. This attribute will be set to whenever the account was created if the password was never reset. There were 76,157 total users in the "Unity Computers" OU of the Unity domain.

I am certain that the accounts with a pwdLastSet date of 5/17/2006 were random and the passwords have not been reset since the accounts were generated because all of the resets occurred between 11:00 AM and 2:00 PM, the time the accounts were all recreated:

------------------------------------------------
Password resets on 5/17/2006 by hour:

Hour: 11:00 (Total: 1714)
Hour: 12:00 (Total: 10423)
Hour: 13:00 (Total: 8097)

Total users found by hour: 20234
------------------------------------------------

20,234 of these users had pwdLastSet dates of 5/16/2006. This means that their passwords were random. Of these users, the ratio of disabled to enabled is approximately 2:1.

------------------------------------------------
Password resets on 5/17/2006 by account status:

Enabled users reset on 5/17/2006: 6599
Disabled users reset on 5/17/2006: 13635
Total users reset on 5/17/2006: 20234
------------------------------------------------

Total users found: 76157
Total users to reset: 20234
------------------------------------------------

The 20,234 users whose password was last reset on 5/17/2006 have had their passwords reset to the default Unity combination.

The RPC Server Unavailable error on SCRIPTS00 has been fixed. I believe the problem occurred because of how the DNS suffix search order was configured. It was set to only search unity.ad.ncsu.edu. I changed it to search unity.ad.ncsu.edu, ad.ncsu.edu, and unity.ncsu.edu.

The account management script is running every 5 minutes again.

Attributes of the Active Directory object for the currently logged in user can be easily retrieved using the VBScript.

As an example, the code below could be added to a script to configure an AFS application (the ncsuAFSPath attribute has been set for all Unity users):

' Connect to AD
set objADInfo = CreateObject("ADSystemInfo")

' Create an object for the account of the currently logged in user
set objUser = getObject("LDAP://" & objADInfo.username)

' Retrieve attribute from Active Directory
ncsuAFSPath = objUser.ncsuAFSPath

' Print the attribute value
WScript.Echo "AFS Path: " & ncsuAFSPath

To list all of the mandatory and optional attributes for a user:

' Connect to AD
set objADInfo = CreateObject("ADSystemInfo")

' Create an object for the account of the currently logged in user
set objUser = getObject("LDAP://" & objADInfo.username)

' Get the class definition for the user
Set objUserClass = GetObject(objUser.Schema)

' Loop through the mandatory attributes
For Each strProperty In objUserClass.MandatoryProperties
wscript.echo "Mandatory Attribute: " & strProperty
Next

' Loop through the optional attributes
For Each strProperty In objUserClass.OptionalProperties
wscript.echo "Optional Attribute: " & strProperty
Next

You could list all of the populated attributes for the user with the code below:

' Connect to AD
set objADInfo = CreateObject("ADSystemInfo")

' Create an object for the account of the currently logged in user
set objUser = getObject("LDAP://" & objADInfo.username)

' Get the information for the user object
On Error Resume Next
objUser.GetInfo

' Get the class definition for the user
Set userClass = GetObject(objUser.Schema)

For Each strProperty In userClass.MandatoryProperties
attrvalues = objUser.Get(strProperty)
If IsArray(attrvalues) Then
For Each Value In attrvalues
wscript.echo "Mandatory Attribute: " & strProperty & " = " & Value
Next
attrvalues = ""
' End If
Else
If Not attrvalues = "" Then
wscript.echo "Mandatory Attribute: " & strProperty & " = " & attrvalues
attrvalues = ""
End If
End If
Next

For Each strProperty In userClass.OptionalProperties
attrvalues = objUser.Get(strProperty)
If IsArray(attrvalues) Then
For Each Value In attrvalues
wscript.echo "Optional Attribute: " & strProperty & " = " & Value
Next
attrvalues = ""
' End If
Else
If Not attrvalues = "" Then
wscript.echo "Optional Attribute: " & strProperty & " = " & attrvalues
attrvalues = ""
End If
End If
Next

This post describes some tests that were conducted to confirm the behavior of the sAMAccountName attribute and if disabling NetBIOS over TCP/IP has any effect on it.

My believe is that the sAMAccountName attribute must be unique across the entire domain even if NetBIOS is disabled on every machine and server. This assumption is based on Microsoft's documentation regarding security principals. Computer, user, and group objects are security principals. Each of these has a mandatory sAMAccountName attribute.

READ MORE

Let week we had some discussions with folks in our security group, to make sure everyone was on the same page regarding privacy and security goals.

With FERPA guidelines and University Legal basically saying that /any/ personally identifyable information needs to be secured, we've got some opportunities ahead.

Our "default" security for AD was seen as reasonable, in that it does not allow any unauthenticated access. Folks "outside" won't be able to troll for usernames.

Our first wee issue is that we need to be able to read an end-user's AFS directory if we're going to be able to mount it. Since the default unity username contains parts of one's name, and because the username is almost certainly part of the AFS path, we need to prevent this data from being readable to anyone but the person doing the mount.

The plan is to find an attribute that we can store the AFS path in the AD user object, and then we can do an authenticated read to access it. We don't want to use the standard "homeDirectory" attribute, 'cause that's to be a Windows UNC path.

This may be useful to the folks doing linux and macs also. Though there is talk of providing access the "account" info via ldap to any campus host, this is a pretty old fashioned limitation to login. Since AD can do both SASL/GSSAPI and x.509 authentication, it may be the thing to use for any sort of remote authenticated access.

All of the AFS implementations I've seen so far just use homeDirectory, and there's nothing particularly useful in the "eduPerson" LDAP schemas I've seen. I'm on the fence about creating our own schema extension to hold this info, or to just overload something already in the directory but not being used.

<rant>
This /could/ be a non-issue, if only we could have users who desired a privacy block get a randomized Unity ID, without forcing this on every single account. If I choose to be user "xyzzy" rather than "jaklein" then my homedir info would not need to be guarded. All one could deduce was that someone had an account on the system, but there would be nothing to link that account to a person.

Apparently, our inability to do this has something to do with Peoplesoft. Go figure.
</rant>

The names, phone numbers, email addresses, IM addresses etc for folks with privacy blocks will have to be protected with ACLS from public view, and the "displayName" set to something non-identifable ("Privacy Blocked User #77 Created 3/20/2007" or somesuch).

Another issue will be group membership. If we roll autogroups for things like classes, we have to protect the membership information. Users (only) will have read rights to the "groups I'm in" attribute on their own account. Users will /not/ have access to the "member" attribute for the group object. As a result, they will know that they are a member of a class or section, but not be able to get a list of who else is a member. The names of groups is more or less public, in that any authenticated user can read it.

Not being able to read "member" will prevent using the class groups for e-mails, though it would be possible to set up rights so that a professor could access this info, assuming it's ok with Legal.

New home directories have been created for all Unity users. These directories are intended to be used as the user's see fit. They will NOT be used for roaming profile data. We intend to enhance and grow the home directories in the future to provide larger amounts of space that is easily available on Windows computes (and others). The home directories reside under \\unity.ad.ncsu.edu\itd\home in directories named a-z. The a-z directories are actually DFS links. This way, the actual directories for the different letters can be volumes which can be moved to different servers for load balancing. The directories currently all reside on 1 volume - \\fs03\home. This will eventually change. Users have Modify permissions on their own directory. Users do not have permissions to list directories under a-z. The user's home directory will be mapped to U: in the new environment.

Some departments may choose to use roaming profiles in the new Active Directory environment. We do not want profile data (mainly the user part of the registry) to be included in users' home direcctories. As a result, profile directories have also been created for all Unity users in the same manner that the home directories are created. The profile directories are not currently linked in DFS because we don't want to make this space obviously available to the users.

Automatic directory quotas have been set for a-z for both home and profile directories. Home directories have a default quota of 100 MB. Profile directories have a default quota of 50 MB. Patrick posted some information about directory quotas here:

http://microsys.unity.ncsu.edu/blog/index.php?title=about_quotas&more=1&c=1&tb=1&pb=1

Read up on directory quotas if you are not familiar with this new feature of Windows Server 2003 R2. There is some good information on Microsoft's site.

I think that I may have discovered another area where using an MIT Kerberos server might get in our way.

I think that the DCOM subsystem, used for both remote administration scripts and for remote assistance, might not be properly authenticated when handed an EOS.NCSU.EDU ticket.

I've had success in running Windows Management Instrumentation (WMI) scripts on remote hosts using a UNITY.AD.NCSU.EDU kerberos ticket, but so far never using EOS. For scripting, this isn't so big a deal, as we'll want to use specialized accounts for any such management, but it does worry me in the area of remote assistance.

Well, this morning I set up an "advanced" folder redirection GPO, and I have some good news, and some bad news...

The bad news is that redirecting the Desktop doesn't work any better with a Windows server as the backend than it does with Novell on the backend. When you make a change (create a desktop folder) the server doesn't send a timely update notification, so the change dosen't appear until you press F5. I think redirecting Desktop is pretty much just not going to work for us, which is truely unfortunate. :-(

The good news is that we can redirect user folders based on group membership. Redirectable folders are "Application Data, Desktop, My Documents," and "Start Menu." So if we have a group with different quota or backup needs, we can automajically move them to another server/share. I could also use DFS paths in the folder redirection, so we have /some/ future-proofing (remember all the user attributes that had to change when we changed our Novell cluster's name?) And finally, the policy includes what to do should the policy ever be un-applied. Don't forget to check the box that sez "copy the files back to the workstation" when redirection is stopped. :-)

I've made share named "Home" kept on fs00 and linked under \\unity.ad.ncsu.edu\itd\Home . I created the "Microsys Staff" folder, my workstation automatically created the "jaklein" directory and set permissions (correctly). "Microsys Staff" should be readable by everyone in the "Microsys Staff" group, but not outside of that group.

There is also a share named "profiles" on fs00 that isn't linked into DFS, for experimentation with roaming profiles that users don't actually ever see.

I have updated the code that verifies our AD accounts against Sybase to make sure they match. It now include a few additional attributes:

gidNumber - numeric identifier of primary group user is member of
(hes_db: userinfo.gid)

uidNumber - unique numeric identifier for user
(hes_db: userinfo.uid)

loginShell - unix shell user uses
(hes_db: userinfo.loginShell)

gecos - full name of user
(xfer_db: ldap_data.prefix, ldap_data.pref_firstname, ldap_data.pref_middlename, ldap_data.pref_lastname)

The gecos attribute will be set to the user's preferred prefix, first, middle, and last name if they have set these. If not, it will be set to the name ordinary first, middle, and last name.

I did not include the homeDirectory attribute because I don't think we want to set this to the user's AFS path. The posixUser class's homeDirectory attribute has the same name as the regular user class. This is the attribute that maps to the Home Folder - Local Path setting under a user's properties.

The newly populated attributes do not appear in the properties listed in Users and Computers. You can use ASDI Edit or another LDAP browser to see them.

The script that checks and updates existing accounts has been run and these attributes should be set on accounts that have already been created. I need to update the daily account management script to include these attributes. I have suspended the execution of the script for now until I can update it.

Just ran into the first local instance of the dreaded MS bug handling transitive trusts.

I had problems deleting some files (ok, it was ConsoleOne) from my C: drive. This surprised me, 'cause I'm supposed to be local admin. What surprised me more was that I couldn't take ownership, as I wasn't an admin, and the files were owned by jaklein@UNITY.AD.NCSU.EDU !

CONTROL-ALT-DELETE showed that I was actually logged in as jaklein@EOS.NCSU.EDU as was my custom, until now.

What should have happened is that MS's Security Provider Interface should have looked at the UNITY.AD account, seen that it had a kerberos principal @EOS, and aquired the proper credentials. What did happen is that MS SPI broke because EOS is an MIT kerberos server. It would have worked if it had been another active directory.

So, for our best practices and documentation, I'd suggest that we have folks set their GINAs to login to @UNITY.AD . The MS-GINA can figure out transitive trusts, but not the whole system just yet.