Synching Passwords Across Multiple Trees with DirXML
Novell Cool Solutions: Trench
By Brian Potter, Nik Nikiforou, Peter J Strifas, Sean Welsh
Digg This -
Posted: 28 Dec 2001
Thanks to the DSI Core Engineering Group at Mount Sinai/NYU Health Organization (named above) for working through this problem, documenting it, and letting us study their notes.
In most DirXML deployments, password management is high on the list of things to do. We've read in many places how DirXML can synchronize the password of NDS users across any and all eDirectory trees in your environment. We've also read how you can synchronize this password for NT using NDS4NT/User Account Manager 2.1.
There's one small piece of information that appears to be missing from all the documentation out there. How the password for NT is actually created and used.
We have 3 eDirectory trees -- one for our production environment (INF), one for our portal (APP) and a 3rd tree for management (WKF). NDS4NT is installed and used in the INF tree (primarily for Citrix).
User management occurs in the WKF tree. HelpDesk and Admins make password resets there. DirXML does well to push the changes across to INF and APP trees. Users logged in to our portal change their own password (via a Java applet) which DirXML pushes out to WKF then on to INF.
Our design did well mananging and pushing NDS passwords through our system. What we didn't take into account was the NDS4NT passwords. All the documentation states that DirXML does not sync passwords for NT -- so we were prepared to have NDS4NT do this for us. In our minds, we covered all the bases. DirXML pushed the necessary NDS-based passwords and NDS4NT would take care of the NT side.
Silly us. Passwords did not synchronize between NDS and NT. After a 2-day crash course in NDS4NT password synchronization processes, we discovered that DirXML and the utilities employed did NOT create the necessary MD4-NT keys. This process is handled by client32 code making calls the the MS API on a workstation.
[If you're using ConsoleOne, you're probably logged into a workstation with client32. NWADMN32 has a snap-in for NDS4NT as well as the client on the workstation. Invoking the password change process triggers the client32 libraries to make the calls to the underlying OS.]
We received a suggestion that NLDAP.NLM created both keys (the RSA-NetWare and MD4-NT keys). This was a major piece of the "missing link" in our solution. Another piece came from a Novell Consultant who was developing our custom iManage console. He went back into his lab and checked the password data changes with NLDAP -- what he found was that it would only work if the user was a member of a domain. Didn't care which domain -- just that a query on the Domain Membership property came back "true". Otherwise the MD4-NT hash was not created.
Problem was, how does one create a domain object in a tree without installing and managing NDS4NT? We thought why not use DirXML?
We went back to our drivers and reset the filters to allow the Domain information through. Specifically, we added all the IWS attributes for User, moved the IWS Domain class (with attributes = IWS Member, IWS Privileges, IWS RID Counter, IWS SID and GUID) and lastly, the IWS Group class (with attributes = CN, GUID, IWS Alias Membership, IWS Attribute, IWS Member, IWS Privileges, IWS RID, IWS SecurityDescriptor). We set these parameters in all our filters (in the 3 trees).
From the DirXML driver in the INF tree, we did a Migrate from NDS for the Domain objects (we have 2). Once the Domain objects passed through, we did another Migrate from NDS for the Groups (better safe than sorry).
The last thing was to re-migrate our users (a resync would not populate the IWS user attributes for some reason) to ensure that the attributes were present in all 3 trees.At this point, we did a simple test using ldapmodify.exe (from the LDAP SDK on Developer.Novell.com) with a simple test.LDIF file and test.bat file.
LDIF file (called test.ldif):
(dn = full dn of user object / userPassword = the new password)
rem Change the three values below to match your environment
rem Also change the name and password as necessary in test.ldif
ldapmodify -D %user% -w %password% -h %server% -f test.ldif
(user = user with rights to change password / server = ip address of server)
Make sure that your server will accept clear text passwords for this test -- you can set this for SSL later for production.
Hope this helps someone else.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com