LDAP Users and Groups - Create new user, gid == uid, and username == group?

I really hope I'm overlooking something, because if not it means I'll be gutting the LDAP Users and Groups module to duplicate functionality. Bleh.

It looks as though routines need to be put in to check the System Users and Groups config, look at the chosen methods, and then call (I think?) useradmin::mkuid($username); or useradmin::berkeley_cksum($username);

Is that right? Both routines look like they return a hash, not an integer. :

While I'm on about asking questions....

FreeBSD's master.passwd is very similar to linux's /etc/shadow file, in that the password hashes are stored there, chmod 600 root.

I took that file, and with a few well placed regexes, formatted the file the way webmin wants to see it. Life is good, import the file, all goes well.

Now, I had told the LDAP users and groups module to use Unix MD5 for all new users. Per the FreeBSD handbook, this is correct:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/crypt.html

All of my password strings started with $1, thus MD5. I can't actually authenticate though. When I go back and look, webmin has prefixed all of the strings with {MD5}. Is this typical behavior, or am I missing something? Further, the setting in LDAP Users and Groups says "for new users", however if I do a password reset, it follows that setting as well, which is fine, but the wording really needs to be changed...

Wow, this just gets stranger by the moment.

I have my customers being created under cn=users,cn=customers,dc=oss-solutions,dc=com. Open Directory puts employee accounts under cn=users,dc=oss-solutions,dc=com. Here's where it gets bizarre. I tried the JXplorer to connect, which works fine, all of the users I imported show up just fine. What's odd is that the application won't show you the full password hash, but rather it has a "Verify password" feature. I can't verify any passwords, new accounts, or osx created accounts.

So I pulled back the webmin config and had it point at the dn users, rather users/customers. What I saw confuses me. Under "Pre-encrypted password, it says ********. Literally. The newer accounts say {md5}!1 whatever.

The fun part is, I can log into macs using those other accounts, and for extra credit, I have authn_ldap running under apache to protect our backuppc install. Those users can log into apache, but the new ones cannot. ????

diradmin is the "directory administrator" account. I've tried binding as diradmin, and root (both should have master privs over ldap), and both still shows asterisks.

Anyone seen this behavior before? I'm completely baffled.

This hasn't been much fun at all.

My research turned up something frustrating. I came across this in my migration from OSX 10.2->10.3 a few years back, and now it's made an appearance in OpenDirectory.

Back in 10.2, if I wanted to get password hashes as root for migration, backups, whatever, I could use nidump passwd .] passwd.txt. It would look more or less like a FreeBSD master.passwd or a Linux /etc/shadow file. As of 10.3, using that gives you what would look like /etc/passwd, that is, instead of the password hash, you get an x. Of course you can't do nidump shadow . or nidump master.passwd either. :( So I hosed the passwords of all of my imported users from FreeBSD. I wound up blowing away the box, installing 10.2, importing the users, then upgrading to 10.3. I got lucky back then.

Well, this time around they've hacked up OpenLDAP. If you attempt, even as a priveleged account, to pull the userPassword attribute, you will get asterisks. I logged in directly to the box, and did an ldapsearch like this:

ldapsearch -D 'uid=root,cn=users,dc=oss-solutions,dc=com' -b 'cn=users,dc=oss-solutions,dc=com' -x -W 'objectclass=*' uid userPassword

The response was frustrating to say the least:

# tshadwick, users, oss-solutions.com
dn: uid=tshadwick,cn=users,dc=oss-solutions,dc=com
userPassword:: KioqKioqKio=
uid: tshadwick

# kshadwick, users, oss-solutions.com
dn: uid=kshadwick,cn=users,dc=oss-solutions,dc=com
userPassword:: KioqKioqKio=
uid: kshadwick

# lgriffith, users, oss-solutions.com
dn: uid=lgriffith,cn=users,dc=oss-solutions,dc=com
userPassword:: KioqKioqKio=
uid: lgriffith
uid: lael

The userPassword field on all users is identical, this stupid KioqKioqKio=. Googling that string returns all sorts of people trying to debug LDAP issues on OSX, but I came across only one post that explains what is happening, which is that despite claiming to NOT use NetInfo (thus nidump, or NetInfo Dump), password hashes are stored in NetInfo, and CANNOT be accessed via LDAP in any way, shape, or form, not matter what user you are. What I have found in the past is that you can't get at it via NetInfo either, so migrating users away from OpenDirectory becomes a sheer impossibility. You CAN auth users against straight up OpenLDAP on macs, I've done that before, but I didn't realize Apple hid the userPassword attribute from everyone, including root.

This is where things get ugly though. When you set up OpenDirectory, you'll set up your base dn, which defaults to dc=servername,dc=zone,dc=tld. If you're wise, you changed this to be just dc=zone,dc=tld. You then have a pair of cn's - cn=users, and cn=groups. If users are added via the Apple Workgroup Manager application, you get the setup described above, along with an apple-specific attribute named authAuthority, which will look something like this (edited to protect myself):

authAuthority: ;Kerberosv5;0x45fb046a76d88e290000000500000005;tshadwick@OSS-SO
LUTIONS.COM;OSS-SOLUTIONS.COM;1024 35 151065087552365604662078053629772612290
45125389744913980776132487212157823612004728815565315294408927808088960236758
82710557542789104971305777382703096824342050137771832808789442594222322573212
7494992662855xxxxxxxxxxxxxxxxxxxxxxxxxx4014428908067293849022
106544972630274236718090726484292219531 root@directory-server.oss-solutions.c
om:x.x.x.x

Apparently this is what Apple uses to tell OpenLDAP where to find the actual password hashes. What's annoying however is that the utilities that generate this information are only available on OSX server, and secondly, presume that all users are going into cn=users,dc=zone,dc=tld. This is a problem because I want to keep company users separated from customers. I literally have cn=users,cn=customers,dc=zone,dc=tld, and a matching group entry. The apple utils won't allow you to properly generate an account. Whenenver you go to remotely auth, EVEN IF you have the right hash in userPassword, if you didn't go back and make it a 'proper' Open Directory account, the auth will fail. So the company accounts work for logging into webmin, or even into the Virtualmin box via ssh or login (once PAM was set up for said box), but the new accounts generated via LDAP Users and Groups fail. If you attempt to reset a password of a company user via LDAP Users and Groups, you will effectively lock that user out.

I'm looking at what I can do to right this situation, as I really only want to maintain a single LDAP structure, and by all rights what I'm doing *should* work. The fact that I'm having these issues is an act of idiocy. If there's an authAuthority field, fine. If not, behave as LDAP should. What's so hard about that? :

It looks like a found a page that lays out some of the more annoying aspects of this. Hopefully I find an acceptable solution to post back here.

http://www.macshadows.com/kb/index.php?title=Mac_OS_X_password_hashes

Finally got it!

Okay - here's how it goes...this doesn't change the fact that if you don't put your users where OpenDirectory expects to find them, Workgroup Manager won't list them. No big loss for me, but I may look into it later.

For users that will actually be logging into macs, you would notice that there are multiple authority entries. For my user I had:

authAuthority: ;ApplePasswordServer
authAuthority: ;Kerberosv5

Now, by designating my users as apple-user accounts (which I did because I'm considering offering some iDisk-type features for end users, and possibly even letting them host home directory replicas with us), OpenDirectory expected to find an authAuthority entry, which I had, but it was blank. The solution to this is to

1: Create and populate the authAuthority element.
2: Have a plausible way to auth.

For me, this was dead simple. These users are going to be created and managed by webmin, so I simply populated authAuthority with ;basic;.

As soon as I did this, my new webmin users began working. I'm sure I'll come back to doing authAuthority Kerberosv5 later, but for now this is at least getting me back on track. My only concern now is getting manually created users to have an automatically created group and match the userid and group, which doesn't happen.