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

8 posts / 0 new
Last post
#1 Wed, 05/23/2007 - 15:07

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

Okay, here's the quick and dirty version of what I have set up. Under System Users and Groups, module config I have:

Default UID/GID Method: Calculated Calculation Method: Berkley Cksum Create new Group For New Users? Yes Assign same ID to new user and group? Yes efault primary group for new users: Default

Over in LDAP Users and Groups I have:

Other objectClasses to add to new users: shadowAccount extensibleObject organizationalPerson person top apple-user (OSX OpenDirectory server apple* stuff IS valid)

Other objectClasses to add to new groups: apple-group extensibleObject

Show fields for given name and surname? Yes

objectClass to add for given name: inetOrgPerson

LDAP Properties for all new users: sn: ${REAL}

Lowest UID for new users: From Users and Groups module Lowest GID for new groups: From Users and Groups module

Default primary group for new users: From Users and Groups module

Unfortunately, no group gets created, no calculations get done. If I click on "Create New User", fill in the forms and leave Primary Group blank, I get the following error: Failed to save user : '' is not a valid group

If I manually fill it in with the new username, I get this: Failed to save user : 'username' is not a valid group

So...apparently LDAP Users and Groups doesn't check with System Users and groups about the automatic creation and calculation thing. Is there a workaround for this other than manually creating the group first? I have a large batch of users that need to be entered, and this could get tedious in a hurry. :(

Sun, 06/07/2009 - 07:03

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. :

Sun, 06/07/2009 - 07:03

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:


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...

Sun, 06/07/2009 - 07:03

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.

Sun, 06/07/2009 - 07:03

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
106544972630274236718090726484292219531 root@directory-server.oss-solutions.c

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? :

Sun, 06/07/2009 - 07:03

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.


Sun, 06/07/2009 - 07:03

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.

Fri, 10/23/2009 - 04:47 (Reply to #7)

I have same problem with Centos 5.3 + Virtualmin installation. Since I don't find any thing similar to "authAuthority" configuration, is there any way to solve it in Centos Linux?

Topic locked