Leopard: Users from external LDAP server can’t login to clients

[speleo]

Hi all

I have already posted this question on the Mac OS X server mailing list, but no one was able to help me there. I noticed that there are a lot of questions related to integration of OD and other LDAP servers on this list, so maybe someone here can help me. I’m really getting desperate…

Our setup is a magic triangle with the following components:

– A university-wide OpenLDAP server, called Uni-LDAP, to which we have read-only access. Every member of our university (students and employees) has an account on this server. Among the attributes of those records are a user name and a password (plus some others that we don’t need). However, the Uni-LDAP user records do not have a GUID attribute. We use this Uni-LDAP server for authentication.
– An OD server that is under our control, running OS X server 10.5.2. The OD server is connected to the Uni-LDAP server. We create user groups on the OD server and populate them with Uni-LDAP users. We’d like to use the OD server to manage who has access to which client computers and to manage those clients and user groups (pref panes, apps, mounting share points etc.)
– 10 client computers running 10.5.2 (G5 Dual 1.8GHz, fresh install), connected to our OD server and the Uni-LDAP server.

What we are doing is this (and this worked fine under 10.4):

– Connect the client computers to the Uni-LDAP.
– Connect the OD server to the Uni-LDAP server.
– Bind the client computers to the OD server. Create a computer list called, for example, “CourseG5” and put the clients into that list. Manage certain preferences for that computer list.
– Create a user group on the OD server, populate them with users records from the Uni-LDAP server, for example, create a group for a student course called “Bio123” and add the Uni-LDAP accounts of the 20 or so students that will participate in this course. Again, manage certain prefs.
– Allow the group “Bio123” to access the client computers of the list “CourseG5” by managing the preference “Login”, tab “Access”, of the computer group.
– Try to log in to one of the G5s as a member of “Bio123″…. and get a shaking login window.

– Remove the group “Bio123” from the computer group “CourseG5”, that is, remove it from the “Login” preference of that list. Now Uni-LDAP users can log in, but ALL Uni-LDAP users can do so. But that’s not what we want – only the 20 students of the course “Bio123” should be allowed to log in to those client G5s.

Interestingly, if I create a test user on the OD server, call it “testOD”, and put the user “testOD” also in the group “Bio123” and give “Bio123” access to the computers of “CourseG5”, user “testOD” can log in, while all Uni-LDAP users in the same group still can’t. If “testOD” isn’t a member of “Bio123”, he can’t log in – just as it should be.

I have tried everything I could think of: Create new groups, use existing groups and add new users to them, use the GUI for adding group members, use the command line instead… nothing, just the shaking login window. I put DirectoryService into debug mode on the OD server, but I wasn’t able to find out anything from the log, it’s a bit too cryptic for me. I even set up a new OD server for testing only, a clean install running OD service only – still nothing.
I even thought that this behavior looks as if “Allow” would be taken on the client for “Deny”, and changed the access control list to “Deny” in the Login pref of the computer group in WGM. Didn’t work, unfortunately. The client seems to just ignore a “Deny”. Again, ALL Uni-LDAP users were able to log in, those that were members of the group that was denied access and everybody else, too.

I do have a suspicion, though:
The users on the Uni-LDAP server do not have a GUID attribute. If I try to give a Uni-LDAP user access to a computer list directly, i.e. if I don’t put the user into a (OD) user group first, WGM complains that it could not give that user access because it does not have a GUID. When I add a Uni-LDAP user to a user group on the OD server, a GUID is created for that user and stored in the group attribute “GroupMembers”. The value is created by taking the Hex value of the user ID on the Uni-LDAP server and concatenating that value to “FFFFEEEE-DDDD-CCCC-BBBB-AAAA0000”. For example, my UID on the Uni-LDAP is 33997 = 0x84CD. Thus, if I add my Uni-LDAP user account to a group on the OD server, the value “FFFFEEEE-DDDD-CCCC-BBBB-AAAA000084CD” is added to the attribute “GroupMembers” of that OD group.
Might my problem be related to the fact that our Uni-LDAP users don’t have GUID? Under 10.5, this seems to have become a rather important attribute? Or am I looking into the completely wrong direction? Or could this be a bug on the client side?

I’d be glad for any ideas, since I’m really, really stuck here, and I have no clue as to what I should try next. I could go back to 10.4 for the server and the G5 clients, but we’d like to add other clients as well, and some of them can’t run 10.4. I did some tests about managing 10.5 clients with a 10.4 OD server, and the results were, well, not very encouraging. I just can’t imagine that this setup should no longer work with 10.5!

Thanks, Tina

[speleo]

Hello again

Well, obviously no one is having a similar problem… but maybe some of you can help me out with some information which might enable me to find ot what’s wrong myself.
So I did some (many) tests, including setting up a 10.4 test server with a 10.4 test client to try and find out what exactly the difference is between managing user access in 10.4 an 10.5 (and to make sure that I’m not starting to imagine things and it WAS actually working under 10.4!). There are some questions remaining, though.

Fact is, the management of user / group access to computers is done very differntly in 10.4 and 10.5:
In 10.5, the GUID of user groups that are allowed to access computers of a computer group is stored in the respective ComputerGroup in the attribute “MCXSettings” in the key “Allow-List”. The OD server then sends the file com.apple.loginwindow.plist to the client, where it is stored in /Library/ManagedPreferences.
In 10.4, the short names of authorized user groups are stored in the ComputerList in the attribute “apple-computer-list-group” (I haven’t found out how the list of these groups gets to the client, and where it is stored there, if it is at all).
Thus, the difference between 10.4 and 10.5 is a) how the authorized groups are stored (short name vs. GUID) and b) where they are stored (apple-computer-list-groups vs. MCXSettings). If a user group contains users from an external LDAP server, access control to a computer list /group works for those users under 10.4 (i.e. members of that group can log in, non-members can’t), whereas it doesn’t work under 10.5 (no LDAP users can log in, regardless whether they are a member or not). Access management does work under 10.4 and 10.5 for users that are defined on the OD server itself.

Now, my question:
A managed client gets sent the short name / GUID of the group(s) that are allowed to log in to that client (this is done differently on 10.4 and 10.5), but then, how does the client find out which users belong to that group? Does it go and check that group on the OD?
Cause I suspect that this might be my problem on 10.5, that either the client or the OD doesn’t recognize users from the extrenal LDAP server as belonging to a group that is allowed to log in… maybe?

Thanks, Tina

[Author]

Posts