Synchronizing SFU Attributes with RFC2307 Attributes

In a very short span of time, I received multiple requests for a script that can sync the values from SFU attributes to RFC2307 attributes. This isn't a new request but it pretty much pointed out that some information is missing and people run in to this situation which should arise in the first place.

The first scenario is where Server for NIS is not at all used and LDAP authentication is implemented using SFU attributes and when AD schema is upgraded to W2K3 R2 or later, there is an option to use RFC2307 attributes. There is no tool available to this. Second scenario is where Server for NIS is in use.

When a W2K3 R2 or later based DC is introduced in a domain where SFU 3.X Server for NIS is functioning, all that is needed is that you just go ahead and install the IdMU Server for NIS and/or Password Synchronization components. If this is in-box upgrade, you have to uninstall the SFU Server for NIS component and select to save the NIS information when prompted. Later, when IdMU Server for NIS component is being installed, you will to choose to restore the the information if prompted.

Both of the above ensure the process copies the information from the SFU schema attributes to newer RFC2307 attributes. Now you need to install hot fix from KB921599 all of the SFU based servers. This hot fix enables the SFU Server for NIS and Password Synchronization component to use the RFC2307 attribute instead of SFU schema.

The in-box upgrade doesn't create a problem but if the KB921599 is not installed on the DCs running SFU version, after a while you would notice that the objects that were updated using the UNIX Attribute tab from SFU-based DCs, contain the UNIX identity information in SFU attributes while the newer DCs store the the information in RFC2307 attributes. This is a problem since now the snap-in cannot be used to properly modify the objects that were touched using the other version. This will also result in mismatched information when querying this information from NIS clients.

If this happens, the way out is that you sync the information by reimporting the information using the nis2ad command line tool or using the NIS migration wizard. But, all the accounts that are updated in the process will be disabled and you will have to enable them and change their passwords. My experience indicates this is not a favored solution among the system administrators.

The easiest way out would be to use a script to copy the information from SFU attributes to RFC2307 attibute and the following script can help you do that without causing the accounts to get disabled -

On Error Resume Next

set objWShell = WScript.CreateObject ("WScript.Shell")
WINDIR = objWShell.Environment.Item ("WINDIR")
Set objRootDSE = GetObject ("
LDAP://rootDSE")
Set strBase = GetObject ("LDAP://" & objRootDSE.Get ("defaultNamingContext") )
BaseDN = strBase.distinguishedname
strBase = "<LDAP://" & BaseDN & ">;"
strFilter = "(objectClass=user);"
strScope = "SubTree"
strAttrs = "distinguishedName,msSFU30Name;"
Set objCon = CreateObject ("ADODB.Connection")
objCon.Provider = "ADSDSOOBJECT"
objCon.Open "Active Directory Provider"
Set cmAD = CreateObject("ADODB.Command")
cmAD.ActiveConnection = objCon
cmAD.CommandText = strBase & strFilter & strAttrs & strScope
cmAD.Properties("Page Size")  = 1000
Set objRes = cmAD.Execute

objRes.MoveFirst
while not objRes.EOF

  if objRes.Fields ("msSFU30Name").Value <> "" Then
 Wscript.echo "Syncing SFU attributes to RFC2307 attributes for " & objRes.Fields ("msSFU30Name").Value & "..."

 strDN = objRes.Fields ("distinguishedName").Value

 Set objUser = GetObject("LDAP://" & strDN )
 objUser.GetInfo
 strUidNumber = objUser.msSFU30UidNumber
 strGidNumber = objUser.msSFU30GidNumber
 strHomeDir= objUser.msSFU30HomeDirectory
 strShell = objUser.msSFU30LoginShell

 objUser.Put "uidNumber", strUidNumber
 objUser.Put "gidNumber", strGidNumber
 objUser.Put "unixHomeDirectory", strHomeDir
 objUser.Put "loginShell", strShell
 objUser.SetInfo

  End if
  objRes.MoveNext
wend
 

It worked well in the test lab but feel free to leave comments or drop me an email if you face a problem or have suggestions to improve this script.

Disclaimer: This script is provided here on as is basis and no representations can be made regarding the quality, safety, or suitability of any code or information found here.