There are a couple of parts to Identity Management for Unix from what I've been told (I have never worked professionally on Windows). There's a snap in to Users and Computers that allows you to set the four attributes that are needed: gidNumber, loginShell, uidNumber, and unixHomeDirectory (I map gecos to displayName).
However I believe there's also Microsoft's NIS support, including an NIS server. I don't believe that it's possible to install the snap-in without getting the NIS support, and our admins don't want it on the domain controllers. I wouldn't blame them.
Anyhow, during the transition our AD admins used ADSI edit to do the field changes (since our pool of users isn't very big), and they created a webform that our Account Administrators can use going forward that populates the four fields on existing accounts. In our environment it's trivial to populate those four fields as we have everyone in the same base group, everyone has the same shell, their home directory is based on their domain and username, and their uidNumber is their PeopleSoft ID. Very easy to determine programmatically.
I don't know what kind of Windows environment you're in, and if your admins are cool with installing IMfU then it should be a bit easier for you - just make sure that the folks adding users don't screw up the data entry.
My larger point was that you don't need IMfU to actually provide the services - there's no "support" that's being provided, the only piece you're using is the GUI snap in.
As far as the LDIF goes, that's just the format of the file (LDAP dump, essentially). In the previous thread we were talking about two different files.
Originally, I was thinking I needed to extend the schema and I asked for an LDIF of the the schema changes so that my AD admin could extend it manually. Once I realized that I didn't need to extend the schema I had Monty@HP Support send me a working LDIF of the ldapux_profile.ldif. This profile contains the LDAP configuration, and serves the same function as /etc/ldap.conf on other servers where NSS_LDAP is used.
In a "normal" LDAP-UX deployment this file consists of the data downloaded by ldapuxclientd from the AD server (from the Profile object created by the schema extension) and compiled into the profile cache (ldapux_profile.bin). I short-circuited that behavior. Once I adapted it to my environment (which is trivial if you've done this before, and a little daunting if you're new) everything worked just great.
To summarize, this is how I believe the LDAP-UX client daemon works, by default:
1) Looks at ldapux_client.conf under the [profile] section to see where to find it's profile information and how to generate the profile cache once it's downloaded.
2) It downloads the profile information from the LDAP server and generates the profile cache (ldapux_profile.bin) using create_profile_cache by default.
3) It uses the profile cache and the authentication cache (pcred) and does its business.
In what we're doing, here's what's happening:
1) ldapuxclientd reads ldapux_client.conf and finds nothing under [profile], and as a result does nothing.
2) It uses the profile cache already present and the authentication cache (pcred) and does its business.
Essentially we cut out the middle step. HP was nice enough to make the requisite tool (create_profile_cache) standalone, and was nice enough to have that tool be able to read from a flat file, making this method trivial to execute.
I'd argue that for fairly consistent and static environments (and I'd argue that most environments are like that), it's much easier to do things this way as the configuration can be deployed non-interactively. It's very easy to script this deployment method. Here's a sample of how to deploy an updated profile (should your domain controller change, for example):
# scp -p updated_ldapux_profile.ldif server.example.com:/etc/opt/ldapux/ldapux_profile.ldif
# ssh root@server.example.com create_profile_cache
# ssh root@server.example.com "/sbin/init.d/ldapclientd.rc stop"
# ssh root@server.example.com "/sbin/init.d/ldapclientd.rc start"
That's it. If you change your auth add pcred to that as well. The nice thing about pcred is that if you use the same bind account on multiple servers you can use the same compiled pcred file as well. I seem to recall that "restart" didn't work right with the ldapclientd.rc script, but it could have been PEBCAK on my part - I just put both lines in the script early on and never bothered to figure out why it didn't work that once, so YMMV.
Overall I found the LDAP-UX product to be very nice to use, and found that it had great documentation, with the sole exception of the setup utility, which I found to be awkward and somewhat unnecessary (at least for our environment). I think that if the local profile method that I used is documented better and if certain things (like handling of spaces and unusual characters) within the setup program are handled better HP will have a truly excellent product.
Please take everything I say with a grain of salt. I had never done any in-depth work with Unix/Linux authentication, LDAP, or Kerberos before I started this project last July. I was tasked with migrating all authentication to AD and I Googled my way through mountains of outdated HOWTOs and misleading information. I do not have any in-depth knowledge of Windows or HP-UX - my expertise is in Linux, IRIX, and some Solaris. I feel I have a very good working knowledge of the technologies, but not a comprehensive understanding.
Coming from this background, I found that it took me a week to figure out how to get this done in Linux, and about a month to fine-tune (mostly because nscd is a piece of crap). By way of comparison, it took me about a month to figure out how to get this done in HP-UX (because of the setup utility and the schema extension), but only a week to fine-tune it. If the local profile option were documented better I think that LDAP-UX would be much easier to set up and deploy than the current solutions in Linux (though if SSSD ships with RHEL6 that might change).
Good luck, feel free to ping me with other questions. I have this thread set up to email me on responses.
