hi all,
please, may somebody advice
I need to set separate credentials for each service I provide (optionally) to my users
I think of something like this:
dn: uid=target-user,ou=People,dc=ibs userPassword: ****** ... authorizedService: xmpp authorizedService: smtp authorizedService: pop authorizedService: imap authorizedService: mail ... loginSMTP: mail-send-login passwSMTP: xxx loginPOP3: mail-get-login passwPOP3: yyy ... loginXMPP: login-xmpp passwXMPP: zzz
can I achieve it? from which side to approach the issue?
On 08/01/13 10:41 +0300, Zeus Panchenko wrote:
hi all,
please, may somebody advice
I need to set separate credentials for each service I provide (optionally) to my users
I think of something like this:
dn: uid=target-user,ou=People,dc=ibs userPassword: ****** ... authorizedService: xmpp authorizedService: smtp authorizedService: pop authorizedService: imap authorizedService: mail ... loginSMTP: mail-send-login passwSMTP: xxx loginPOP3: mail-get-login passwPOP3: yyy ... loginXMPP: login-xmpp passwXMPP: zzz
This has been discussed on the list at least a couple of times. Search the archives for keywords 'authorization' 'pam' 'radius'.
On Thu, Aug 01, 2013 at 10:41:25AM +0300, Zeus Panchenko wrote:
I need to set separate credentials for each service I provide (optionally) to my users
That seems perverse - most of us work hard to *reduce* the number of different usernames and passwords that each person has to use!
I think of something like this:
dn: uid=target-user,ou=People,dc=ibs userPassword: ****** ... authorizedService: xmpp authorizedService: smtp authorizedService: pop authorizedService: imap authorizedService: mail ... loginSMTP: mail-send-login passwSMTP: xxx loginPOP3: mail-get-login passwPOP3: yyy ... loginXMPP: login-xmpp passwXMPP: zzz
You would end up creating two new attributes for each service type, and OpenLDAP would still not check the passwords for you in a useful way.
Better method: Create a sub-entry below the user entry for each service. The service-specific entry can use the standard 'uid' and 'userPassword' attributes, and you just need to make sure that each service includes the authorizedService attribute when searching for the entry to authenticate. Something like this:
dn: uid=target-user,ou=People,dc=ibs uid: target-user cn: sn:
dn: authorizedService=smtp,uid=target-user,ou=People,dc=ibs authorizedService: smtp uid: mail-send-login userPassword: ******
dn: authorizedService=pop3,uid=target-user,ou=People,dc=ibs authorizedService: pop3 uid: mail-get-login userPassword: ******
Your SMTP server would issue searches of the form:
(&(uid=USERNAME)(authorizedService=smtp))
Your POP3 server would issue searches of the form:
(&(uid=USERNAME)(authorizedService=pop3))
Andrew
Andrew Findlay wrote:
On Thu, Aug 01, 2013 at 10:41:25AM +0300, Zeus Panchenko wrote:
I need to set separate credentials for each service I provide (optionally) to my users
That seems perverse - most of us work hard to *reduce* the number of different usernames and passwords that each person has to use!
The one-account-for-everything is not suitable for all security policies.
Especially when Android smartphones store clear-text (WLAN) passwords into Google cloud...
Ciao, Michael.
Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
Better method: Create a sub-entry below the user entry for each service. ... Something like this:
dn: uid=target-user,ou=People,dc=ibs ... Your SMTP server would issue searches of the form: (&(uid=USERNAME)(authorizedService=smtp))
thank you very much
it does just what I was thinking about in my initial post!
Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
... You would end up creating two new attributes for each service type, and OpenLDAP would still not check the passwords for you in a useful way.
Better method: Create a sub-entry below the user entry for each service. The service-specific entry can use the standard 'uid' and 'userPassword' attributes, and you just need to make sure that each service includes the authorizedService attribute when searching for the entry to authenticate. ...
is there way to avoid target service uid clashing in this case?
lets say I have two users with name John and I need to give each one acces to some service, but both of them wish the service uid=john (for example, it is common issue for MTA serving different mail domains with different user space for each one)
so what is needed to provide uniqueness of attribute `uid' for each
dn: authorizedService=target-service,uid=target-user,ou=People,dc=org
is it possible to do that inside OpenLDAP or have it to be performed via something like analyzing the output of
ldapsearch ... "(&(uid=target-user)(authorizedService=target-service))" dn
On Fri, Aug 09, 2013 at 01:20:55PM +0300, Zeus Panchenko wrote:
is there way to avoid target service uid clashing in this case?
lets say I have two users with name John and I need to give each one acces to some service, but both of them wish the service uid=john (for example, it is common issue for MTA serving different mail domains with different user space for each one)
The first question to ask is how the application is going to tell the difference between the two users when someone tries to login as 'john'.
If the users are john@a.b.com and john@x.y.org then why not use the full mail address as the uid?
so what is needed to provide uniqueness of attribute `uid' for each
dn: authorizedService=target-service,uid=target-user,ou=People,dc=org
If each 'john' account exists in a distinct identifiable namespace then you could either put the name of the namespace in the account entry or you could use it as part of the LDAP hierachy. The application can then formulate a search that finds the correct entry in one operation.
Namespace in account:
Search base: ou=People,dc=org Search filter: "(&(uid=target-user)(namespace=x.y.com)(authorizedService=target-service))"
Namespace in hierachy:
Search base: ou=People,namespace=x.y.com,dc=org Search filter: "(&(uid=target-user)(authorizedService=target-service))"
[ 'namespace' is used as an example here. There is no such attribute type in the standard schema ]
Andrew
Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
lets say I have two users with name John and I need to give each one acces to some service, but both of them wish the service uid=john (for example, it is common issue for MTA serving different mail domains with different user space for each one)
The first question to ask is how the application is going to tell the difference between the two users when someone tries to login as 'john'.
If the users are john@a.b.com and john@x.y.org then why not use the full mail address as the uid?
yes, it is what I was thought about too and I like the idea, though I wanted to check how correct/right is this way
so what is needed to provide uniqueness of attribute `uid' for each dn: authorizedService=target-service,uid=target-user,ou=People,dc=org
perhaps I need to define more accurately what I mean:
the uniqueness while *creating* the dn ... since for dn-s
dn: authorizedService=target-service,uid=target-user1,ou=People,dc=org dn: authorizedService=target-service,uid=target-user2,ou=People,dc=org ... dn: authorizedService=target-service,uid=target-userN,ou=People,dc=org
I want to prevent the possibility to create the same uid=john-whatever-format-it-is
now I do can ldapadd these ldif-s successfully ---[ ldif ]------------------------------------------------------------ dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org cn: john.doe@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 uid: john
dn: authorizedService=xmpp.org,uid=jsmith,ou=People,dc=org authorizedService: xmpp.org cn: john.smith@xmpp.org sn: xmpp.org description: John Smith XMPP account at xmpp.org uidNumber: 12356 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject uid: john ---[ ldif ]------------------------------------------------------------
and
ldapsearch ... "(&(uid=john)(authorizedService=xmpp.org))"
outputs both of them, so I need the way I can know that uid: is not unique while creating the dn:
so, what I need to prevent the possibility to create the second dn:, since it will contain the same uid value as the first one?
If each 'john' account exists in a distinct identifiable namespace then you could either put the name of the namespace in the account entry or you could use it as part of the LDAP hierachy. The application can then formulate a search that finds the correct entry in one operation.
I was thinking to use sn: attribute since it is login dedicated dn: and it is no need in it
but all the same, my question remains oppened: how to not to create not unique uid for dn: authorizedService=target-service,uid= ?
have I put in into UI for records management or it can be done on the server side (for example like indexes in SQL)
On Fri, Aug 09, 2013 at 04:17:02PM +0300, Zeus Panchenko wrote:
the uniqueness while *creating* the dn ... since for dn-s
dn: authorizedService=target-service,uid=target-user1,ou=People,dc=org dn: authorizedService=target-service,uid=target-user2,ou=People,dc=org ... dn: authorizedService=target-service,uid=target-userN,ou=People,dc=org
I want to prevent the possibility to create the same uid=john-whatever-format-it-is
If you always put the uid in the DN using the structure shown above then it will not be possible to create duplicates. That assumes that you use the same uid in all the subentries of the main user entry...
now I do can ldapadd these ldif-s successfully ---[ ldif ]------------------------------------------------------------ dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org cn: john.doe@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 uid: john
dn: authorizedService=xmpp.org,uid=jsmith,ou=People,dc=org authorizedService: xmpp.org cn: john.smith@xmpp.org sn: xmpp.org description: John Smith XMPP account at xmpp.org uidNumber: 12356 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject uid: john ---[ ldif ]------------------------------------------------------------
Both those entries have one uid in the entry and a different one in the DN. The one in the DN refers to the parent entry in each case so it is legal but maybe not what you want.
It may be enough for you to simply prevent the non-uniqueness. You can do that using the 'unique' overlay:
overlay unique unique_uri ldap:///ou=People,dc=org?uid?sub
Unfortunately this creates another problem: *every entry* must have a different uid - probably not what you want...
It would be possible to write an access-control list using sets to require that the two uids match. This is not quite as simple as there are various cases to consider. Again it may be too restrictive, as then every sub-entry would have to have the same uid as the main entry (though the passwords could still be different).
If each 'john' account exists in a distinct identifiable namespace then you could either put the name of the namespace in the account entry or you could use it as part of the LDAP hierachy. The application can then formulate a search that finds the correct entry in one operation.
I was thinking to use sn: attribute since it is login dedicated dn: and it is no need in it
The data you are putting there is clearly *not* a surname. Don't misuse attributes like this - it will cause trouble later. A more appropriate attribute might be associatedDomain - you will need to add the objectclass 'domainRelatedObject' as well.
Andrew
Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
now I do can ldapadd these ldif-s successfully ---[ ldif ]------------------------------------------------------------ dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org ... uid: john
dn: authorizedService=xmpp.org,uid=jsmith,ou=People,dc=org authorizedService: xmpp.org ... uid: john ---[ ldif ]------------------------------------------------------------
Both those entries have one uid in the entry and a different one in the DN. The one in the DN refers to the parent entry in each case so it is legal but maybe not what you want.
no, it is, indeed
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
in particular, I do not see another way to authenticate users of different domains(for email)/realms(for xmpp) against the same LDAP DB
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
something like:
dn: authorizedService=target-service,uid=target-service_ALLOWED-USER,ou=People,dc=org authorizedService=target-service uid=UNIQUE-AMONG-ALL_target-service_USERS-VALUE
Just crazy idea...
several attributes for user passwords (userPassword1, userPassword2, ...) in user account and proxy-mapping overlay (slapo-translucent? slapo-rwm?) with mapping attribute userPassword into userPassword1 or userPassword2 with dependencies from service IP.
WBR
On 09.08.2013 17:17, Zeus Panchenko wrote:
Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
lets say I have two users with name John and I need to give each one acces to some service, but both of them wish the service uid=john (for example, it is common issue for MTA serving different mail domains with different user space for each one)
The first question to ask is how the application is going to tell the difference between the two users when someone tries to login as 'john'.
If the users are john@a.b.com and john@x.y.org then why not use the full mail address as the uid?
yes, it is what I was thought about too and I like the idea, though I wanted to check how correct/right is this way
so what is needed to provide uniqueness of attribute `uid' for each dn: authorizedService=target-service,uid=target-user,ou=People,dc=org
perhaps I need to define more accurately what I mean:
the uniqueness while *creating* the dn ... since for dn-s
dn: authorizedService=target-service,uid=target-user1,ou=People,dc=org dn: authorizedService=target-service,uid=target-user2,ou=People,dc=org ... dn: authorizedService=target-service,uid=target-userN,ou=People,dc=org
I want to prevent the possibility to create the same uid=john-whatever-format-it-is
now I do can ldapadd these ldif-s successfully ---[ ldif ]------------------------------------------------------------ dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org cn: john.doe@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 uid: john
dn: authorizedService=xmpp.org,uid=jsmith,ou=People,dc=org authorizedService: xmpp.org cn: john.smith@xmpp.org sn: xmpp.org description: John Smith XMPP account at xmpp.org uidNumber: 12356 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject uid: john ---[ ldif ]------------------------------------------------------------
and
ldapsearch ... "(&(uid=john)(authorizedService=xmpp.org))"
outputs both of them, so I need the way I can know that uid: is not unique while creating the dn:
so, what I need to prevent the possibility to create the second dn:, since it will contain the same uid value as the first one?
If each 'john' account exists in a distinct identifiable namespace then you could either put the name of the namespace in the account entry or you could use it as part of the LDAP hierachy. The application can then formulate a search that finds the correct entry in one operation.
I was thinking to use sn: attribute since it is login dedicated dn: and it is no need in it
but all the same, my question remains oppened: how to not to create not unique uid for dn: authorizedService=target-service,uid= ?
have I put in into UI for records management or it can be done on the server side (for example like indexes in SQL)
openldap-technical@openldap.org
-
Andrew Findlay -
Dan White -
Dmitriy Kirhlarov -
Michael Ströder -
Zeus Panchenko