Hey, Certainly new to migrations of LDAP. I migrated our old setup from OpenLDAP to 389 Directory Server. When using the "id" command on an LDAP client, it only returns uid,gid, and one group. It for some reason does not show all of the actual groups that the user is associated with. What is set to return these values and what setting ensures they are properly mapped from OpenLDAP to 389DS?
### OpenLDAP example: ###
[root openldapclient ~]# id jedmands uid=9999(jedmands) gid=100(users) groups=100(users),5000(manager),5001(linuxadmin),5002(storageadmin),5003(dbadmin),5004(webadmin),5006(it)
### 389 DS Example: ###
[root 389dsclient ~]# id jedmands uid=9999(jedmands) gid=100(users) groups=100(users)
Notes: Posted this to the 389-users list, nothing received. We are using the memberOf plugin for 389DS. I don't know too much about the openldap environment. I moved to CentOS 6 and figured DS was the way to go with SSL/TLS
--On Thursday, September 05, 2013 1:11 PM -0400 Justin Edmands shockwavecs@gmail.com wrote:
Hey, Certainly new to migrations of LDAP. I migrated our old setup from OpenLDAP to 389 Directory Server. When using the "id" command on an LDAP client, it only returns uid,gid, and one group. It for some reason does not show all of the actual groups that the user is associated with. What is set to return these values and what setting ensures they are properly mapped from OpenLDAP to 389DS?
I suggest you migrate back to OpenLDAP where things work. This list is for questions about OpenLDAP, not 389. If the 389 user list is generating no results, that should tell you something too.
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Justin Edmands wrote:
Hey, Certainly new to migrations of LDAP. I migrated our old setup from OpenLDAP to 389 Directory Server. When using the "id" command on an LDAP client, it only returns uid,gid, and one group. It for some reason does not show all of the actual groups that the user is associated with. What is set to return these values and what setting ensures they are properly mapped from OpenLDAP to 389DS?
### OpenLDAP example: ###
[root openldapclient ~]# id jedmands uid=9999(jedmands) gid=100(users) groups=100(users),5000(manager),5001(linuxadmin),5002(storageadmin),5003(dbadmin),5004(webadmin),5006(it)
### 389 DS Example: ###
[root 389dsclient ~]# id jedmands uid=9999(jedmands) gid=100(users) groups=100(users)
Notes: Posted this to the 389-users list, nothing received. We are using the memberOf plugin for 389DS. I don't know too much about the openldap environment. I moved to CentOS 6 and figured DS was the way to go with SSL/TLS
I'm pretty sure you figured wrong. OpenLDAP actually works, implements the LDAP RFCs correctly, and outperforms all other LDAP servers. Compared to 389DS, OpenLDAP bulk-loads data 2x faster, uses 10% less space on disk, answers search queries 4x faster, and uses 50% less RAM to do it. (Also answers Binds 6x faster, and performs updates 11x faster.) 389DS is a hulking pile of obsolete code; the only reason it still exists today is because RedHat has support contracts for RedHatDS from customers too ignorant to realize how bad the product they've paid for actually is.
On Thu, Sep 5, 2013 at 1:36 PM, Howard Chu hyc@symas.com wrote:
Justin Edmands wrote:
Hey, Certainly new to migrations of LDAP. I migrated our old setup from OpenLDAP to 389 Directory Server. When using the "id" command on an LDAP client, it only returns uid,gid, and one group. It for some reason does not show all of the actual groups that the user is associated with. What is set to return these values and what setting ensures they are properly mapped from OpenLDAP to 389DS?
### OpenLDAP example: ###
[root openldapclient ~]# id jedmands uid=9999(jedmands) gid=100(users) groups=100(users),5000(**manager),5001(linuxadmin),** 5002(storageadmin),5003(**dbadmin),5004(webadmin),5006(**it)
### 389 DS Example: ###
[root 389dsclient ~]# id jedmands uid=9999(jedmands) gid=100(users) groups=100(users)
Notes: Posted this to the 389-users list, nothing received. We are using the memberOf plugin for 389DS. I don't know too much about the openldap environment. I moved to CentOS 6 and figured DS was the way to go with SSL/TLS
I'm pretty sure you figured wrong. OpenLDAP actually works, implements the LDAP RFCs correctly, and outperforms all other LDAP servers. Compared to 389DS, OpenLDAP bulk-loads data 2x faster, uses 10% less space on disk, answers search queries 4x faster, and uses 50% less RAM to do it. (Also answers Binds 6x faster, and performs updates 11x faster.) 389DS is a hulking pile of obsolete code; the only reason it still exists today is because RedHat has support contracts for RedHatDS from customers too ignorant to realize how bad the product they've paid for actually is.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/**project/http://www.openldap.org/project/
Thank god you got that off of your chest. the solution is:
/etc/sssd/sssd.conf [domain/default] .. ldap_group_member = memberUid ldap_group_search_base = ou=Group,dc=mysite,dc=com ..
after flushing cache, the clients see the proper groups.
Justin Edmands wrote:
Thank god you got that off of your chest. the solution is:
And OpenLDAP actually has a knowledgeable community that responds to posts, and gives correct answers.
/etc/sssd/sssd.conf [domain/default] .. ldap_group_member = memberUid
You should look into switching to RFC2307bis; using non-DNs for references within an LDAP directory is a really bad idea.
ldap_group_search_base = ou=Group,dc=mysite,dc=com ..after flushing cache, the clients see the proper groups.
That should concern you too. You're now knowingly relying on a caching mechanism that serves stale data for your systems' base security. You should look into using OpenLDAP nssov+pcache instead; pcache has active cache refresh among other things so you don't need to restart or flush anything to keep your system security up to date.
openldap-technical@openldap.org
-
Howard Chu -
Justin Edmands -
Quanah Gibson-Mount