9:13 a.m.
On Fri, Aug 09, 2013 at 05:53:57PM +0300, Zeus Panchenko wrote:
To: Andrew Findlay <andrew.findlay(a)skills-1st.co.uk>
Please keep replies on the list so that they become searchable
and everyone can benefit.
here is the diagram depicting what I am thinking about while talking
:)
https://www.dropbox.com/s/212kdpbiug9obkc/org-ldap-diagram-plane.png
I dedicate these DN-s for services, so each such DN *can and supposed
to*
use any (in theory) uid in the entry, the user can ask for
Do you reall want every user account on every service to have a
different username? (i.e. the user cannot request to be known as
'fred' on both the SMTP service and the IMAP service?
in particular, I do not see another way to authenticate users of
different domains(for email)/realms(for xmpp) against the same LDAP DB
That depends on how you provide the services. If the network address
of the services used by domain-A users is different from that used by
domain-B users then the server processes will know which domain they
are serving. If the same network address is used to serve all domains
then you do indeed require the uids to be unique across domains (but
you probably do want to let fred(a)x.y.com use that ID for all
services).
> It may be enough for you to simply prevent the non-uniqueness.
You can
> do that using the 'unique' overlay:
mmm ... will not it prevent non-uniqueness only for parent DN-s? while
what I'm trying to ask (I'm sorry for muddled up explanation what I mean)
about is - uniqueness for the uid *in* the entry ... so, the uniqueness
of the attribute `uid' among all DN-s containing authorizedService=target-service
You could do that if you are prepared to have one config line for each
service. Something like:
overlay unique
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH)
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:36 p.m.
New subject: separate login/password for several services?
Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> wrote:
Do you reall want every user account on every service to have a
different username?
to be honest, I do not want, but in practice when I need to land some
mail domain with whole it's users at my MTA, I need to decide what
to do with widely used mailboxes like admin, info, abuse etc
(i.e. the user cannot request to be known as
'fred' on both the SMTP service and the IMAP service?
technically I do can provide that but it is head ache of course and what
I meant is difference in more "other" protocols like smtp/pop3/imap4 -
xmpp - rdp - ftp - ssh - whatever else
are serving. If the same network address is used to serve all
domains
then you do indeed require the uids to be unique across domains (but
you probably do want to let fred(a)x.y.com use that ID for all
services).
yes, I do
> mmm ... will not it prevent non-uniqueness only for parent DN-s?
while
> what I'm trying to ask (I'm sorry for muddled up explanation what I mean)
> about is - uniqueness for the uid *in* the entry ... so, the uniqueness
> of the attribute `uid' among all DN-s containing
authorizedService=target-service
You could do that if you are prepared to have one config line for each
service. Something like:
overlay unique
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH)
wow, great! since the number of the services I provide is limited, it is
not the problem to set all of them in slapd.conf
thank you much!
and finally, is it OK (strategically) that object person becomes the
branch rather than leaf in such configuration?
--
Zeus V. Panchenko jid:zeus@im.ibs.dn.ua
IT Dpt., I.B.S. LLC GMT+2 (EET)
3:23 p.m.
New subject: separate login/password for several services?
Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> wrote:
> mmm ... will not it prevent non-uniqueness only for parent DN-s?
while
> what I'm trying to ask (I'm sorry for muddled up explanation what I mean)
> about is - uniqueness for the uid *in* the entry ... so, the uniqueness
> of the attribute `uid' among all DN-s containing
authorizedService=target-service
You could do that if you are prepared to have one config line for each
service. Something like:
overlay unique
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP)
unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH)
this prevents each uid=X,ou=People,dc=org from having more than one
authorizedService=Y offspring ... while the original idea is to let user
A to have for the service B, several uid-s but to prevent other users to
have the same uids for the corresponding service ...
what I mean are multiple attributes uid/userpassword "inside" the
offspring not in the `dn' of the offspring:
dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
authorizedService: xmpp.org
uid: john
uid: john1
uid: johnN
userPassword: qwerty
userPassword: qwerty1
userPassword: qwertyN
cn: john.doe(a)xmpp.org
sn: xmpp.org
description: John Doe XMPP account at xmpp.org
uidNumber: 12345
gidNumber: 23456
homeDirectory: /nonexistent
loginShell: /sbin/nologin
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: authorizedServiceObject
and in this case we need to prevent some other user from having
offspring with the same uid ... to prevent for user
uid=johandoe,ou=People,dc=org offspring:
dn: authorizedService=xmpp.org,uid=johandoe,ou=People,dc=org
authorizedService: xmpp.org
uid: johan
uid: johan1
userPassword: qwerty
userPassword: qwerty1
cn: johan.doe(a)xmpp.org
sn: xmpp.org
description: Johan Doe XMPP account at xmpp.org
uidNumber: 12345
gidNumber: 23456
homeDirectory: /nonexistent
loginShell: /sbin/nologin
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: authorizedServiceObject
possibility to add another `uid: johnN' which is already used by
dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
so, what could be the solution, please?
--
Zeus V. Panchenko jid:zeus@im.ibs.dn.ua
IT Dpt., I.B.S. LLC GMT+2 (EET)
1:23 a.m.
New subject: separate login/password for several services?
On Fri, Sep 27, 2013 at 01:23:54AM -2100, Zeus Panchenko wrote:
> overlay unique
> unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP)
> unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP)
> unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3)
> unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP)
> unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH)
>
this prevents each uid=X,ou=People,dc=org from having more than one
authorizedService=Y offspring ... while the original idea is to let user
A to have for the service B, several uid-s but to prevent other users to
have the same uids for the corresponding service ...
what I mean are multiple attributes uid/userpassword "inside" the
offspring not in the `dn' of the offspring:
That can be done - it is just a matter of choosing a naming structure
that allows it.
dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
authorizedService: xmpp.org
uid: john
uid: john1
uid: johnN
userPassword: qwerty
userPassword: qwerty1
userPassword: qwertyN
cn: john.doe(a)xmpp.org
sn: xmpp.org
description: John Doe XMPP account at xmpp.org
uidNumber: 12345
gidNumber: 23456
homeDirectory: /nonexistent
loginShell: /sbin/nologin
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: authorizedServiceObject
That one won't work, as there is no way to link the individual uid and
userPassword values. You need one LDAP entry per uid so either add
another layer to the tree or use multi-valued RDNs. The tree version
would look like this:
dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
authorizedService: xmpp.org
....
dn: uid=john,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
authorizedService: xmpp.org
uid: john
userPassword: qwerty
....
dn: uid=john1,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
authorizedService: xmpp.org
uid: john1
userPassword: qwerty1
....
dn: uid=johnN,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
authorizedService: xmpp.org
uid: johnN
userPassword: qwertyN
....
The multi-valued RDNs version like this:
dn: uid=john+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
authorizedService: xmpp.org
uid: john
userPassword: qwerty
....
dn: uid=john1+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
authorizedService: xmpp.org
uid: john1
userPassword: qwerty1
....
dn: uid=johnN+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
authorizedService: xmpp.org
uid: johnN
userPassword: qwertyN
....
and in this case we need to prevent some other user from having
offspring with the same uid ... to prevent for user
uid=johandoe,ou=People,dc=org offspring:
dn: authorizedService=xmpp.org,uid=johandoe,ou=People,dc=org
authorizedService: xmpp.org
uid: johan
uid: johan1
userPassword: qwerty
userPassword: qwerty1
cn: johan.doe(a)xmpp.org
sn: xmpp.org
description: Johan Doe XMPP account at xmpp.org
uidNumber: 12345
gidNumber: 23456
homeDirectory: /nonexistent
loginShell: /sbin/nologin
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: authorizedServiceObject
possibility to add another `uid: johnN' which is already used by
dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
That should already be covered by the unique overlay setup.
Incidentally, you seem to be misusung some fields in the person
object:
cn: john.doe(a)xmpp.org
sn: xmpp.org
If you really don't want to put the real name there you should choose
a different objectclass that does not force you to fill in those
attributes.
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 |
-----------------------------------------------------------------------
4:25 a.m.
New subject: separate login/password for several services?
Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> wrote:
That can be done - it is just a matter of choosing a naming
structure
that allows it.
that's simple but was not obvious to me :(
That one won't work, as there is no way to link the individual
uid and
userPassword values. You need one LDAP entry per uid so either add
another layer to the tree
dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
authorizedService: xmpp.org
....
dn: uid=john,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
authorizedService: xmpp.org
uid: john
userPassword: qwerty
....
I like it, thanks much
have I create dedicated object like:
dn: authorizedService=YYY,uid=AAA,dc=ZZZ
before configuring the service for the user like:
dn: uid=XXX,authorizedService=YYY,uid=AAA,dc=ZZZ
or the second one will be enough?
Incidentally, you seem to be misusung some fields in the person
object:
> cn: john.doe(a)xmpp.org
> sn: xmpp.org
If you really don't want to put the real name there you should choose
a different objectclass that does not force you to fill in those
attributes.
it is not to say I do not want to put it, but rather I want to have such
possibility in case it could be demanded in the future
as for the different classes ... I was trying to find it but faced the
problem when the parent record, which contains
objectclass: posixAccount
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: inetLocalMailRecipient
was refusing the child creation until the child belongs to that set of
classes :(
--
Zeus V. Panchenko jid:zeus@im.ibs.dn.ua
IT Dpt., I.B.S. LLC GMT+2 (EET)
4:53 a.m.
New subject: separate login/password for several services?
On Fri, Sep 27, 2013 at 02:25:24PM +0300, Zeus Panchenko wrote:
have I create dedicated object like:
dn: authorizedService=YYY,uid=AAA,dc=ZZZ
before configuring the service for the user like:
dn: uid=XXX,authorizedService=YYY,uid=AAA,dc=ZZZ
or the second one will be enough?
You have to create the branch points before you can add entries under
them. That is why I suggested the alternative where both the service
name and the uid are part of the RDN: such multi-valued RDNs are
unusual, but it might be a convenient structure in this case.
as for the different classes ... I was trying to find it but faced
the
problem when the parent record, which contains
objectclass: posixAccount
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: inetLocalMailRecipient
was refusing the child creation until the child belongs to that set of
classes :(
There must have been some other reason for the error. LDAP servers do
not normally restrict what type of entry you can create at a given
point in the DIT. The ACLs in force might restrict what you can do,
but you have control over those.
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:16 p.m.
New subject: separate login/password for several services?
Andrew Findlay wrote:
That should already be covered by the unique overlay setup.
Did not follow this thread closely. But one should be aware of ITS#6825 when
planning to use slapo-unique for a more complex setup.
unique_uri filter reaching beyond its intended target
http://www.openldap.org/its/index.cgi?findid=6825
Ciao, Michael.
4:04 a.m.
New subject: separate login/password for several services?
On Fri, Sep 27, 2013 at 10:16:43PM +0200, Michael Ströder wrote:
Did not follow this thread closely. But one should be aware of
ITS#6825 when
planning to use slapo-unique for a more complex setup.
unique_uri filter reaching beyond its intended target
http://www.openldap.org/its/index.cgi?findid=6825
Good point. We started with these ACLs:
> overlay unique
> unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP)
> unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP)
> unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3)
> unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP)
> unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH)
so that bug will prevent modifications to the authority entries even though adds
will be processed OK. I cannot think of an easy workaround in this case :-(
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 |
-----------------------------------------------------------------------
3653
days inactive
3705
days old
openldap-technical@openldap.org
7 comments
3 participants
participants (3)
-
Andrew Findlay -
Michael Ströder -
Zeus Panchenko