[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Ldap challenge
Thanks,
I will read over this and see if I can make it work.
Daniel
________________________________________
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Sent: Monday, April 27, 2015 3:06 PM
To: Ross, Daniel B.
Cc: openldap-technical@openldap.org
Subject: Re: Ldap challenge
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%20authentication
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
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------