Active Directory AND SunLDAP

[JP]

We have a Windows AD domain in which all our user accounts must exist for access to our Windows infrastructure (files server, exchange etc) and we will most likely also use Windows for obtaining a Kerberos TGT at login. Fine and dandy.
We also have a large Sun infrastructure and need a directory server product which they can talk to natively to, for which we would prefer to use SunOne DS. The reasons for choosing Sun DS over Apple’s OpenDirectory are we get Sun level of support and Sun ship a tool for synchronising users between Sun DS and MS AD – effectively users have one password. So we have a few choices when deciding how to configure the authentication on the OS X workstations:

1) Authenticate to AD using the AD plugin

2) Authenticate to AD using the LDAPv3 plugin

3) Authenticate to Sun DS using the LDAPv3 plugin

4) Authenticate to Apple DS using the LDAPv3 plugin

5) Authenticate direct to Kerberos by modifying the loginwindow.app in /etc/authorization.

Now I’ll take you through the problems we identified so far,

With option 1 users will not get any information other than uid/gid/homedir, MCX settings cannot be applied per user and group membership for groups in the Sun/Apple DS will not be applied. May require schema change depending on how it is implemeneted. We can apply ‘per machine’ MCX settings however.

With option 2 we can theoretically store anything we need in AD (but we will need to modify the AD schema – which is a no-no and beyond our control). Also as with option 1 no UNIX groups applied.

With option 3 there is no issue with changing the schema or chopping and changing it after it goes live. BUT – as with option 2 – there is no password policy feedback to the user, this is a big problem. We need to force “change password at next logon” and such like. The Apple LDAP plug-in doesn’t appear to interpret this unless we use a Password server.

So if we use Apple’s password server – as in option 4 – we get all the password feed back we need to the user… but there is no password sync product available from Apple to sync with Microsoft AD.

With option 5 we still get no password policy feedback but have the flexability to store any other information in any of the directories with whatever limitations I have already described.

We really need to have expiry/lockout/force change etc feedback to the user with the solution we deploy but as you can see with the options currently available from Apple there are other problems caused by using these.

Currently option 1 is the best compromise we can get, using machine level MCX settings… anyone got other ideas?
[/b]

[JP]

Joel

The documentation does indeed say:
Both Kerberos & OpenDirectory Password server enforce password policies.

However, how am I supposed to enable the Kerberos option on 10.3 without editing /etc/authorization – Apple say you have to set the password type to Open Directory…. but if I do that, then I can’t use my LDAP <-> AD password synch tool which requires Crypt password in LDAP.

Unfortunately the services we need from the Suns aren’t Kerberized, so we need the AD password (Kerberos one) to be the same as the user’s password in LDAP.

Maybe I’m missing something obvious here. It seems I’m so close to what we need but none of the options give us all of the answers.

[JP]

Joel

Yeah, that’s the theory, but it simply doesn’t work.
I point at the LDAP server as the only thing in the Authentication tab of Directory Services and can log in with a testuser network account. This testuser exists in the LDAP and AD with the same password. Fine (FYI, we are using Apple’s schema, just hosting it on a Sun).

Next, I get my edu.mit.Kerberos file to point at AD – I can get Kerberos tickets manually (with the Get tickets button in the gui or kinit).

Next, I reboot and disable the testuser account in AD. This *should* prevent login shouldn’t it?

But I can login still (since LDAP allows me in) but of course I can’t get a Kerberos ticket.

Set password to expire in AD and I can still login but I can’t get a Kerberos ticket – the GUI even tells me why – the password has expired.

This is being tested on a virgin 10.3 install – loginwindow.app is just not respecting the Kerberos rules.

All of the above happens whether I mess with /etc/authorization or not. Any ideas?

[Author]

Posts