2015-04-24 19:02 GMT+02:00 Dan White dwhite@cafedemocracy.org:

On 04/22/15 20:08 +0000, Ross, Daniel B. wrote:

...

Ok I have looked a couple options but I really dont know how to accomplish what I need to do.

Here is what I am trying to do.

I have a greater organization that is stuck on using Microsoft products namely Microsoft LDS. To make matters worse they present the data to my linux servers in a completely non-standard way. Its driving my solaris and linux box nuts and they simply dont want to work with it.

What i need to do is continue to use the campus usernames and passwords but present the Data in a format that my linux/unix hosts can use. Is this possible?

i.e. userid would still be samwise but instead of a bizzarre OU=monkeypeople,dc=example,dc=com I want it to present as people,dc=example,dc=com.

I looked at referral and aliasing but it does not seem to be doing what I am trying to do. Passthrough authentication looks close but I cant find sufficient documentation to actually configure a system to use it.

See slapo-rwm(5).

Pass-through is documented in section 14.5 of the Administrator's Guide:

http://www.openldap.org/doc/admin24/

Supporting Cyrus SASL documentation:

http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/ And /saslauthd/LDAP_SASLAUTHD within the Cyrus SASL source.

You'll find workable pass-through examples for authenticating to Exchange in this list's archives as well as the Cyrus SASL list archives. The 'ldap' and 'kerberos5' saslauthd backends should both be workable solutions.

Hi,

you can also find a documentation on SASL delegation here: http://ltb-project.org/wiki/documentation/general/sasl_delegation

Clément.

On Wed, Apr 22, 2015 at 08:08:11PM +0000, Ross, Daniel B. wrote:

What i need to do is continue to use the campus usernames and passwords but present the Data in a format that my linux/unix hosts can use. Is this possible?

Probably, but I don't think you have given us enough information so far.

i.e. userid would still be samwise but instead of a bizzarre OU= monkeypeople,dc=example,dc=com I want it to present as people,dc=example,dc= com.

I assume the latter DN should be O=people,dc=example,dc=com

If this is your main problem then it may not need solving on the server side. There is no fixed rule about the structure of a base DN used for Linux and Unix LDAP authentication. You should be able to work with any DN structure, provided that you know where to base your searches and provided you can do one-level or subtree searches on the AD service to find what you need.

I looked at referral and aliasing but it does not seem to be doing what I am trying to do. Passthrough authentication looks close but I cant find sufficient documentation to actually configure a system to use it.

Does the campus AD service contain everything that Linux/Unix would need? e.g. does it have:

Username (almost certain - called samAccountName in AD) Unix numeric UID Unix numeric GID Unix homedir Unix shell Something to use for GECOS (optional)

It does not matter what those attributes are called in AD as you can set the clients to work with whatever you have, but they *do* have to be present. It used to be necessary to load a Microsoft package called SFU (Services For Unix) to support this, but I think more recent versions of AD already have schema for it by default.

If you don't have at least that set of attributes with sensible values to work with then you will have to maintain a parallel or overlay directory service. There are several ways to do that, so let's start by establishing what you have!

Andrew

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

Interesting how this question is hitting a number of different mailing lists…

Here’s an edited extract of an email I’ve sent yesterday on OpenDJ mailing list:

The memberOf attribute name was used by Microsoft Active Directory with specific semantic. There is no LDAP representation of the attribute definition, but details, including OID, can be found here: https://msdn.microsoft.com/en-us/library/ms677099(v=vs.85).aspx.  It was also used by a Sun product (Delegated Administration) with another definition and semantic.

This is why we choose in Sun Directory Server, OpenDS and now OpenDJ to have a properly defined attribute with a different name: isMemberOf, operational and read-only.

My 2 cents,

Ludo

--  Ludovic Poitou http://ludopoitou.com

From: Michael Ströder michael@stroeder.com Reply: Michael Ströder michael@stroeder.com> Date: 27 Apr 2015 at 22:43:41 To: Andrew Findlay andrew.findlay@skills-1st.co.uk> Cc: openldap-technical@openldap.org openldap-technical@openldap.org> Subject:  Re: Ldap challenge

Andrew Findlay wrote:

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

'isMemberOf' is used on Sun/Oracle DSSE, Netscape/Fedora/389-DS and OpenDS/OpenDJ.

'memberOf' was originally defined in MS Active Directory and is used as default in slapo-memberof. It's configurable though.

Ciao, Michael.

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%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 -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

Marc Patermann wrote:

Hi,

Andrew Findlay schrieb (27.04.2015 21:06 Uhr):

...

On Mon, Apr 27, 2015 at 06:27:39PM +0000, Ross, Daniel B. wrote:

...

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.

I don't know about AD, I googled a bit around. I found "Identity Management for UNIX: Password Synchronization" as a successor of SFU, is this true? Is this the thing MS is currently offering: https://technet.microsoft.com/en-us/library/cc776179%28v=ws.10%29.aspx Using NIS and installing a PAM module on every machine!?

Not the only way.

http://www.openldap.org/lists/openldap-devel/200811/msg00045.html

You can create a slapd overlay that talks to the AD password synch module to do two-way password synchronization.