On Mon, Apr 27, 2015 at 06:27:39PM +0000, Ross, Daniel B. wrote:
ismemberof does not exist we have to use memberof
Memberof is fairly common. I don't think I have ever found a system that used 'ismemberof'.
Note that maintaining memberof takes some work so it is not enabled on all LDAP servers by default.
nsUniqueId we have to use objectGUID
What do you use nsUniqueId for? Probably not a problem anyway as you may be able to use other similar attributes as you mention above.
no uniqueMember again can only use memberof.
uniqueMember and memberOf have completely different use-cases: uniqueMember is used just like 'member' in most cases, to indicate which entries are members of the group that it appears in. memberOf indicates which groups the entry that it appears in is a member of (i.e. it is the inverse mapping).
while there is a guarantee of person there is not the same for Posixaccount or shadowaccount.
Ah - if you lack those attributes then AD is certainly not going to do the job on its own.
While I have been able to get linux with SSSD to work, to some extent, with this its rather hit and miss and the Solaris systems just wont work at all. This is why I was hoping to be able to use the campus for the username and password, and then provide the rest from a local ldap server. It doesnt sound like this is really possible.
Yes - it should be possible but it will take a bit more work.
saslauthd did not work at all with the MS LDS.
Did you try following the instructions here?:
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...
Note that you will need the DN and password of an existing AD user to allow saslauthd to do LDAP searches on AD. You can try the ldapsearch commands from section 14.5.3 without any other setup to test that you have a good user account.
In principle it may be better to do Kerberos authentication against AD rather than LDAP, but I didn't have a Kerberos server handy when I wrote that bit.
What is a parallel or overlay directory service?
Parallel would be where you replicate some subset of data from AD into a local LDAP server, which then operates as a self-contained system. You could have the replication process create or look up Unix-specific attributes like UID and GID for new accounts.
Overlay would be where you use what you can get from AD, and put a translucent overlay on top containing Unix-specific data that you administer locally.
In either case you need to decide how to handle password checking and account locking.
All of my customers so far have chosen the parallel approach, as that allows the Unix LDAP to continue working if it loses access to AD. Ideally this includes installing a module on the AD Domain Controllers that detects password changes and forwards them immediately to the Unix LDAP. I have generally used Microsoft's SFU password-capture module for this as AD admins seem happier to install Microsoft code than things from other sources. It does have its problems though, and the code quality of the Unix end that they provide leaves a lot to be desired. I believe newer AD versions come with an updated version of this built in, but I have not tested it.
Andrew