1:08 p.m.
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.
Thanks
Daniel
10:02 a.m.
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.
--
Dan White
11:59 a.m.
2015-04-24 19:02 GMT+02:00 Dan White <dwhite(a)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.
6:48 a.m.
Will any of this work with the secure 636 connection with TLS? Thats what I have to
connect using. Its not a port 389 connection. I saw this documentation before but
couldn't find anything that said it work over 636.
For further consideration, I also don't have kerberos nor do I have the availability
to install anything on a windows system that is bound to the domain, as that is forbidden.
They would have to control the system and would then not allow anything to be installed
on it.
Daniel
Operating Systems Analyst/Development, Lead
Rollins School of Public Health at Emory University
404-727-9931
Daniel.ross(a)emory.edu
________________________________________
From: Clément OUDOT <clem.oudot(a)gmail.com>
Sent: Friday, April 24, 2015 2:59 PM
To: Dan White
Cc: Ross, Daniel B.; openldap-technical(a)openldap.org
Subject: Re: Ldap challenge
2015-04-24 19:02 GMT+02:00 Dan White <dwhite(a)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.
9:07 a.m.
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
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
11:27 a.m.
I think you are getting to the root of the problem.
So to give you some of the problems.
ismemberof does not exist we have to use memberof
nsUniqueId we have to use objectGUID
no uniqueMember again can only use memberof.
while there is a guarantee of person there is not the same for Posixaccount or
shadowaccount.
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.
saslauthd did not work at all with the MS LDS.
What is a parallel or overlay directory service?
Daniel
________________________________________
From: Andrew Findlay <andrew.findlay(a)skills-1st.co.uk>
Sent: Monday, April 27, 2015 12:07 PM
To: Ross, Daniel B.
Cc: openldap-technical(a)openldap.org
Subject: Re: Ldap challenge
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
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
12:06 p.m.
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%20authenti...
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 |
-----------------------------------------------------------------------
1:42 p.m.
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.
12:50 a.m.
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(a)stroeder.com>
Reply: Michael Ströder <michael(a)stroeder.com>>
Date: 27 Apr 2015 at 22:43:41
To: Andrew Findlay <andrew.findlay(a)skills-1st.co.uk>>
Cc: openldap-technical(a)openldap.org <openldap-technical(a)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.
7:43 a.m.
Ludovic Poitou wrote:
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.
Also FreeIPA IMO abuses 'memberOf' with different semantics.
Ciao, Michael.
6:46 a.m.
Thanks,
I will read over this and see if I can make it work.
Daniel
________________________________________
From: Andrew Findlay <andrew.findlay(a)skills-1st.co.uk>
Sent: Monday, April 27, 2015 3:06 PM
To: Ross, Daniel B.
Cc: openldap-technical(a)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%20authenti...
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 |
-----------------------------------------------------------------------
5:18 a.m.
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!?
Marc
5:34 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3142
days inactive
3150
days old
openldap-technical@openldap.org
12 comments
8 participants
participants (8)
-
Andrew Findlay -
Clément OUDOT -
Dan White -
Howard Chu -
Ludovic Poitou -
Marc Patermann -
Michael Ströder -
Ross, Daniel B.