openldap-technical

openldap-technical@openldap.org

9868 discussions

back-sql: trasnlating examples from slapd.cong to slapd.d
by Alessandro Dentella 25 Sep '15

25 Sep '15

Hi, I'm trying to configure slapd with back-sql (specifically postgresql backend). All documents I found (Postgresq LDAP Howto seems to be more complete) are related to old configuration that use slapd.conf while I need to use the news slapd.d dynamic one. I can't understand how I should add the entry in the configuration. What I currenty tried is: dn: olcDatabase={1}sql,cn=config objectClass: olcDatabaseConfig objectClass: olcSqlConfig olcSuffix: dc=vega,dc=com olcDatabase: sql olcDbName: mytest But when I run ldapmify I get the error: root@argo-jessie:~# ldapmodify -x -D cn=admin,cn=config -W -f ,ldapvi-argo-jessie-7228.ldif Enter LDAP Password: adding new entry "olcDatabase={1}sql,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcSuffix> failed startup And at 254 debugLevel I get: Sep 23 16:34:18 localhost slapd[5650]: olcSuffix: value #0: <olcSuffix> failed startup (dc=vega,dc=com)! Sep 23 16:34:18 localhost slapd[5650]: send_ldap_result: err=80 matched="" text="<olcSuffix> failed startup" I'm making the test on Debian Jessie with slapd versione 2.4.40 sandro *:-) I opended a question on serverfault: http://serverfault.com/questions/724329/slapd-configuration-for-back-sql-ho… -- Sandro Dentella *:-) http://www.reteisi.org Soluzioni libere per le scuole http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy

2 1

ACLs whont work
by Fischer, Johannes 23 Sep '15

23 Sep '15

Hi @all, I struggle with the ACLs, I whant a special account to check the username and PW of the entries on the LDAP-server. Therefore I’ve written the following in the slapd.conf file: access to attrs=userPassword by dn="cn=authenticate,dc=vfk,dc=ldap,dc=com" write by self write by anonymous none access to * by * write by anonymous none But I can’t authenticate to the LDAP server, does somebody know why? Greetings John

4 4

Translucent overlay search fails with TLS "cannot find private key for certificate"
by Ernie Kovak 22 Sep '15

22 Sep '15

Hello - I'm running openldap 2.4.39 on centos 7, using the translucent overlay and moznss for connections to the backend Active Directory server. When I issue a search request for users in the backend directory I get no results and a "server not available" error - see the debug output below. The same slapd.conf configuration, but on centos 5.10 and using OpenSSL, works correctly. So, I imagine it's related to moznss. I've verified (firewall logs) that openldap successfully connects to the backend on startup, but not when the search request is submitted. It looks like it's trying to use client-authenticated TLS, even though the backend is not set up for that?? Any ideas? Thanks! Ernie =============================================================================================== slapd.conf =============================================================================================== include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/we_person_and_npe.schema pidfile /var/run/openldap/slapd.pid loglevel stats #loglevel -1 #loglevel trace conns filter stats # Path to dynamic modules: modulepath /usr/lib64/openldap moduleload back_mdb moduleload back_ldap moduleload translucent moduleload accesslog moduleload auditlog moduleload valsort moduleload ppolicy moduleload memberof # TLS server certs (TLS client config is in ldap.conf) #TLSCACertificateFile /opt/acme/global/certs/ca/ca.pem #TLSCertificateFile /opt/acme/global/certs/server-cert.pem #TLSCertificateKeyFile /opt/acme/global/certs/server-key.pem # not working in our docker container since openldap is linked against NSS and not OpenSSL #TLSCipherSuite TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL:!SSLv2 # path of the directory containing the NSS certificate and key database files TLSCACertificatePath /opt/acme/local/certs/nssdb/ # specifies the name of the certificate to use TLSCertificateFile server # name of a file that contains the password for the key for the certificate specified with TLSCertificateFile TLSCertificateKeyFile /opt/acme/local/certs/.nss_tmp_pwd (contains clear text pasword for keystore and server cert private key) access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=clearance,citizenship,sciControl by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by dn="cn=npe-sts,ou=NPEs,ou=Native,dc=acme,dc=com" read access to attrs=gimmeeOrg,gimmeeRegion,gimmeeTopic,gimmeeIsAICP,gimmeeGroup,gimmeeProject,gimmeeProjectGroup by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by dn="cn=npe-sts,ou=NPEs,ou=Native,dc=acme,dc=com" read access to attrs=UUID by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by users read access to attrs=userPassword by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by self write by anonymous auth access to attrs=currentLoginDate,lastLoginDate,lastFailedLoginDate,currentLoginIpAddr,lastLoginIpAddr,lastFailedLoginIpAddr by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by dn="cn=npe-openid,ou=NPEs,ou=Native,dc=acme,dc=com" write by users read access to * by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by users read by anonymous auth ####################################################################### # Database for Native accounts (NPEs and users) ####################################################################### database mdb suffix "ou=Native,dc=acme,dc=com" rootdn "cn=weAdmin,dc=acme,dc=com" directory "/opt/acme/global/data/openldap/db/native-user-db" subordinate index objectClass eq,pres index ou,cn,mail,surname eq,pres,sub index clearance,scicontrol eq,pres,sub index citizenship eq,pres,sub password-hash {SSHA} # Apply password policy overlay to Native accounts, with a default policy. overlay ppolicy ppolicy_default "cn=default,ou=Policies,ou=Native,dc=acme,dc=com" ppolicy_use_lockout ppolicy_hash_cleartext ####################################################################### # Database for additional attributes for enterprise accounts. ####################################################################### database mdb suffix "dc=acme,dc=com" rootdn "cn=weAdmin,dc=acme,dc=com" rootpw {SSHA}73M5MnfH97O8KAN8anAbneD2wf0C6VSg directory "/opt/acme/global/data/openldap/db/enterprise-user-db" index objectClass eq,pres index ou,cn,mail,surname eq,pres,sub index clearance,scicontrol eq,pres,sub index citizenship eq,pres,sub ####################################################################### # Translucent LDAP proxy to Active Directory ####################################################################### overlay translucent uri "ldaps://atlas.acme.com:636" chase-referrals no idassert-bind bindmethod=simple binddn="cn=devadmin,ou=Users,ou=System Accounts,ou=Acme,dc=acme,dc=com" credentials="******" mode=none tls_cacert=/opt/acme/global/certs/ca/gd-class2-root-2.pem tls_reqcert=demand # Attributes to be searched for in local database. Only the classes that # apply to proxied accounts are candidates for translucent_local: # local wePerson attributes: translucent_local objectClass translucent_local UUID,accountStatus translucent_local rank,grade,position,command,agency translucent_local DSN translucent_local weGrp,weOrg translucent_local clearance,citizenship,scicontrol # wePerson attributes pulled from remote directory: translucent_remote objectClass translucent_remote cn,givenName,sn,mail,o,mobile translucent_remote displayName,sAMAccountName,userPrincipalName =============================================================================================== >From output when setting SLAPD_OPTIONS="-d 65535" =============================================================================================== <snip> loads slapd.conf 55f854a6 config_build_entry: "olcDatabase={2}mdb" 55f854a6 config_build_entry: "olcOverlay={0}translucent" 55f854a6 ==> translucent_cfadd 55f854a6 config_build_entry: "olcDatabase={0}ldap" 55f854a6 config_build_entry: "olcOverlay={1}glue" 55f854a6 backend_startup_one: starting "ou=Native,dc=acme,dc=com" 55f854a6 mdb_db_open: "ou=Native,dc=acme,dc=com" 55f854a6 mdb_db_open: database "ou=Native,dc=acme,dc=com": dbenv_open(/opt/acme/global/data/openldap/db/native-user-db). 55f854a6 mdb_monitor_db_open: monitoring disabled; configure monitor database to enable 55f854a6 backend_startup_one: starting "dc=acme,dc=com" 55f854a6 mdb_db_open: "dc=acme,dc=com" 55f854a6 mdb_db_open: database "dc=acme,dc=com": dbenv_open(/opt/acme/global/data/openldap/db/enterprise-user-db). 55f854a6 ==> translucent_db_open 55f854a6 backend_startup_one: starting "dc=acme,dc=com" 55f854a6 ldap_back_db_open: URI=ldaps://atlas.acme.com:636 55f854a6 ldap_back_monitor_db_open: monitoring disabled; configure monitor database to enable 55f854a6 slapd starting <snip> 55f876ea ==> translucent_search: <dc=acme,dc=com> (sAMAccountName=admin) ldap_create ldap_url_parse_ext(ldaps://atlas.acme.com:636) 55f876ea =>ldap_back_getconn: conn=1000 op=1: lc=0x7f3e581a9950 inserted refcnt=1 rc=0 ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP atlas.acme.com:636 55f876ea daemon: activity on 1 descriptor 55f876ea daemon: activity on:55f876ea 55f876ea daemon: epoll: listen=6 active_threads=0 tvp=NULL 55f876ea daemon: epoll: listen=7 active_threads=0 tvp=NULL ldap_new_socket: 17 ldap_prepare_socket: 17 ldap_connect_to_host: Trying 172.12.3.45:636 ldap_pvt_connect: fd: 17 tm: -1 async: 0 attempting to connect: connect success TLS: certdb config: configDir='/opt/acme/local/certs/nssdb/' tokenDescription='ldap(1)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /opt/acme/local/certs/nssdb/ prefix . TLS: loaded CA certificate file /opt/acme/global/certs/ca/gd-class2-root-2.pem. TLS: certificate 'server' successfully loaded from moznss database. TLS: no unlocked certificate for certificate 'CN=mv22.acme.com ,OU=Development,O=Acme,L=Denver,ST=Colorado,C=US'. TLS: cannot find private key for certificate 'CN=mv22.acme.com,OU=Development,O=Acme,L=Denver,ST=Colorado,C=US' (error -12285: Unable to find the certificate or key necessary for authentication.) TLS: error: unable to set up client certificate authentication for certificate named CN=mv22.acme.com ,OU=Development,O=Acme,L=Denver,ST=Colorado,C=US TLS: error: unable to set up client certificate authentication using 'CN= mv22.acme.com,OU=Development,O=Acme,L=Denver,ST=Colorado,C=US' TLS: error: could not initialize moznss security context - error -12285:Unable to find the certificate or key necessary for authentication. TLS: can't create ssl handle. 55f876ea send_ldap_result: conn=1000 op=1 p=3 55f876ea send_ldap_result: err=52 matched="" text="Proxy operation retry failed"

1 2

funny error
by Fischer, Johannes 22 Sep '15

22 Sep '15

Hi, I’ve just had some funny moments with openldap. I had some bad written code (from my self ☺) where I’ve tried to set a description (2.5.4.13) attribute with an empty string (“”). The result was a error massage: description: value #0 invalid per syntax the best Thing about that is, that the Spring security framework interpreted the error for a following Boolean attribute. This is only for your amusement and to help other with similar problems Greetings John

2 1

seg faults with slapd and libc?
by jason cafarelli 19 Sep '15

19 Sep '15

Hello, centos 6.5 with a basic slapd setup; internal LDAP and proxy to external LDAP Getting segaults every 6 hours or so when I let QA on system and generate some typical user load. All 32 threads halt; ldapsearch stops responding. Typically no logs; last one dropped this: ie: Sep 18 07:47:58 maryann2 kernel: slapd[53754]: segfault at 7f3083ffff98 ip 00007f3104cc3532 sp 00007f30a5ff9660 error 6 in libc-2.12.so [7f3104c4a000+18b000] Should i just sledgehammer a yum update and get off centos 6.5? *Jason K Cafarelli* Desk: (508) 637-5705 (primary) Mobile: (508) 215-9712 jason.cae(a)gmail.com

2 2

HDB compared with LMDB
by Philip Colmer 17 Sep '15

17 Sep '15

We're currently using OpenLDAP 2.4.38 on our production server using HDB as the database type. I wanted to upgrade to the latest version and take advantage of LMDB as the database type so I've built a second server and transferred the data. Before making that server the production server, we're running performance comparisons, using ldclt[1] as a stress test tool. I don't know if anyone else has got any experience of using this tool; the output we're getting when running the tool doesn't show significant differences in performance, but I'm not sure if it is just the test type we're running or the fact that, actually, we shouldn't be expecting significant differences ... I've included the output below. I've removed the details of our servers from the command line. Can someone who has made a transition from HDB to LMDB give an indication of whether or not we should see a performance difference on LDAP queries and, if yes, by what sort of factor? If you are familiar with ldclt, should we be running different tests to get a better insight into how the two servers compare? Thanks. Philip [1] http://docs.oracle.com/cd/E19957-01/816-6400-10/ldclt.html 2.4.38 with HDB: ldclt -f uid=testXXXXX -e esearch,random -r0 -R99999 -I 32 ldclt version 4.23 ldclt[1979]: Starting at Thu Sep 17 11:28:51 2015 ldclt[1979]: Average rate: 109.70/thr ( 109.70/sec), total: 1097 ldclt[1979]: Average rate: 114.80/thr ( 114.80/sec), total: 1148 ldclt[1979]: Average rate: 115.00/thr ( 115.00/sec), total: 1150 ldclt[1979]: Average rate: 111.90/thr ( 111.90/sec), total: 1119 ldclt[1979]: Average rate: 115.20/thr ( 115.20/sec), total: 1152 ldclt[1979]: Average rate: 114.80/thr ( 114.80/sec), total: 1148 ldclt[1979]: Average rate: 113.70/thr ( 113.70/sec), total: 1137 ldclt[1979]: Average rate: 111.20/thr ( 111.20/sec), total: 1112 ldclt[1979]: Average rate: 114.80/thr ( 114.80/sec), total: 1148 ldclt[1979]: Global average rate: 1021.10/thr (113.46/sec), total: 10211 2.4.41 with MDB: ldclt -f uid=testXXXXX -e esearch,random -r0 -R99999 -I 32 ldclt version 4.23 ldclt[1967]: Starting at Thu Sep 17 11:26:55 2015 ldclt[1967]: Average rate: 109.70/thr ( 109.70/sec), total: 1097 ldclt[1967]: Average rate: 111.00/thr ( 111.00/sec), total: 1110 ldclt[1967]: Average rate: 112.20/thr ( 112.20/sec), total: 1122 ldclt[1967]: Average rate: 113.00/thr ( 113.00/sec), total: 1130 ldclt[1967]: Average rate: 112.70/thr ( 112.70/sec), total: 1127 ldclt[1967]: Average rate: 112.50/thr ( 112.50/sec), total: 1125 ldclt[1967]: Average rate: 113.00/thr ( 113.00/sec), total: 1130 ldclt[1967]: Average rate: 112.80/thr ( 112.80/sec), total: 1128 ldclt[1967]: Average rate: 112.30/thr ( 112.30/sec), total: 1123 ldclt[1967]: Average rate: 112.90/thr ( 112.90/sec), total: 1129 ldclt[1967]: Global average rate: 1122.10/thr (112.21/sec), total: 11221

2 2

ldap_result timeout not working?
by Ilja Maki 17 Sep '15

17 Sep '15

Hi, What am I missing as the ldap_result function does not seem to care at all about the timeout value given to it? I would need polling behavior and I have tried to give it a timeval of zero, 2 seconds and other small values but often it does not return until over a minute has passed. I have also tried to call ldap_set_option( m_ldap, LDAP_OPT_TIMEOUT, &timeout ) first where the timeout has been zero, 2 seconds etc. but it does not have any effect either. Sometimes ldap_result takes very long also after a call to ldap_simple_bind but usually this happens after a call to ldap_search_ext. Also abandoning a lengthy ldap_result operation is not an option as ldap_result will throw an access violation if it is given an abandoned message identifier. And without access to the internals of the ldap library I cannot synchronize the abandoning so that it would take place only after ldap_result has proceeded so far that it is ok for it to abandon the identifier. My code used OpenLDAP version 1.168.2.16 where this issue occurred, then I upgraded it to version 2.4.42 to see if it behaves differently (with #define LDAP_DEPRECATED 1 for now for simplicity) but the same issue seems to be there. I am developing and testing with Windows 8.1 but the same issue is also at least in Mac OS. Any help will be greatly appreciated. Thanks! - Ilja -- Learn why you should attend BroadSoft Connections 2015 <http://www.broadsoftconnections.com> This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.

1 0

Strange aliases behavior
by Karol Chrapek 17 Sep '15

17 Sep '15

I have a problem with Slapd and Alias dereferencing. In the ldap we have created a special subtree that allocate logical structure for our application. For this purpose we use the aliases. They allow us in one subtree have normal structure used by our internal services and for second subtree has a dedicate logical structure for special apps. Currently we tested different version of ldap: - 2.4.28 with HDB - 2.4.31 with HDB and MBD - 2.4.41 with mdb - 2.4.42 with MDB <--- this version we are currently using On all version the dereferencing aliases is works very fast when we have about 2000 aliases and about 200000 entries in the Database. When we add additional 2000 aliases each search with aliases dereferencing hangs for 3 second. When we add additional 2000 (so 6000 alieases in DB) the search time increase for next 3 seconds. I.E. search time for filter objectclass=user with -a always for: -2000 aliases in DB is about 0,031s -4000 aliases in DB is about 3,031s -6000 aliases in DB is about 6,123s And this search time was increase even if we add additional 2000 aliases outside the search base dn. We observed that during this 3, 6 second hangs one CPU core is about 100%, system does not wait for resources, memory is on the same level. In the log I saw that slapd very fast dereferencing all aliases in subtree, hang for 3,6,9 seconds depends of aliases count and after that I saw: mdb_dn2entry("cn=.....") Sep 4 14:53:50 ds1 slapd[4280]: => mdb_dn2id("cn=....") Sep 4 14:53:50 ds1 slapd[4280]: <= mdb_dn2id: got id=0x231 Sep 4 14:53:50 ds1 slapd[4280]: => mdb_entry_decode: Sep 4 14:53:50 ds1 slapd[4280]: <= mdb_entry_decode Sep 4 14:53:50 ds1 slapd[4280]: => mdb_filter_candidates Sep 4 14:53:50 ds1 slapd[4280]: #011OR Sep 4 14:53:50 ds1 slapd[4280]: => mdb_list_candidates 0xa1 Sep 4 14:53:50 ds1 slapd[4280]: => mdb_filter_candidates Sep 4 14:53:50 ds1 slapd[4280]: #011EQUALITY Sep 4 14:53:50 ds1 slapd[4280]: => mdb_equality_candidates (objectClass) Sep 4 14:53:50 ds1 slapd[4280]: => key_read Sep 4 14:53:50 ds1 slapd[4280]: <= mdb_index_read: failed (-30798) Sep 4 14:53:50 ds1 slapd[4280]: <= mdb_equality_candidates: id=0, first=0, last=0 Sep 4 14:53:50 ds1 slapd[4280]: <= mdb_filter_candidates: id=0 first=0 last=0 Sep 4 14:53:50 ds1 slapd[4280]: => mdb_filter_candidates Sep 4 14:53:50 ds1 slapd[4280]: #011EQUALITY Sep 4 14:53:50 ds1 slapd[4280]: => mdb_equality_candidates (objectClass) Sep 4 14:53:50 ds1 slapd[4280]: => key_read Sep 4 14:53:50 ds1 slapd[4280]: <= mdb_index_read 3585 candidates Sep 4 14:53:50 ds1 slapd[4280]: <= mdb_equality_candidates: id=3585, first=18960, last=239706 Sep 4 14:53:50 ds1 slapd[4280]: <= mdb_filter_candidates: id=3585 first=18960 last=239706 Sep 4 14:53:50 ds1 slapd[4280]: <= mdb_list_candidates: id=3585 first=18960 last=239706 Sep 4 14:53:50 ds1 slapd[4280]: <= mdb_filter_candidates: id=3585 first=18960 last=239706 Sep 4 14:53:50 ds1 slapd[4280]: mdb_search_candidates: id=3585 first=18960 last=239706 Sep 4 14:53:50 ds1 slapd[4280]: => mdb_entry_decode: Sep 4 14:53:50 ds1 slapd[4280]: <= mdb_entry_decode Sep 4 14:53:50 ds1 slapd[4280]: => test_filter Sep 4 14:53:50 ds1 slapd[4280]: EQUALITY Sep 4 14:53:50 ds1 slapd[4280]: => access_allowed: search access to "cn......." "objectClass" requested Sep 4 14:53:50 ds1 slapd[4280]: <= root access granted After that ldap start return object that is also very fast. When the query was finished I saw in log this info: Sep 4 14:53:50 ds1 slapd[4280]: mdb_search: 18985 scope not okay Sep 4 14:53:50 ds1 slapd[4280]: mdb_search: 18986 scope not okay All other query that not derf. aliases are processed very fast. Search time about 32k entries in subtree without aliases is about 0,526s. Our server DB and indexing settings: maxsize 10737418240 checkpoint 1024 10 sizelimit 100000 maxderefdepth 2 searchstack 10 index accountid eq index objectClass eq index cn eq index id eq index name eq index entryCSN eq index entryUUID eq Do you have any idea how we can tune search with aliases? Regards Karol

3 3

OpenLDAP wildcard searches.
by Michael 16 Sep '15

16 Sep '15

Hello all, I've come across an issue where java developers using one of our LDAP environments want to be able to do wildcard searches on non-standard LDAP attributes. They are using a custom schema in the LDAP environment which contains the following attributes for example. retailerId:jurisdictionID: They want to be able to perform the following search filter to pull all entries with 21 as the jurisdictionID and any wildcard for the retailerID. '(&(retailerId=*)(jurisdictionID=21))' works as expected but of course this returns all objects with any retailerID. They would like to narrow the search results using the filters below. Is there something that needs to be added to the custom schema to allow this to work like it does for the standard LDAP attributes like cn,sn,mail etc? '(&(retailerId=177*)(jurisdictionID=21))' returns zero results'(&(retailerId=*389)(jurisdictionID=21))' returns zero results'(&(retailerId=1*389)(jurisdictionID=21))' returns zero results

5 9

Configuring OpenLDAP server with Linux groups information
by JC 15 Sep '15

15 Sep '15

I have a CentOS system where authentication over the SSH interface is delegated to an OpenLDAP server by means of PAM. This works fine. However, when the authentication succeeds, I would like for the OpenLDAP server to send back group information as well to the CentOS system. That is, the OpenLDAP server should send back a list of groups that the authenticated user will belong to when a shell is created for it in the CentOS box. This information should supersede what groups information local to the CentOS box. I have an LDAP schema in the OpenLDAP server system that almost achieves what I want - but not quite. In the CentOS system I currently have a file named mysite.ldif with the following contents: # extended LDIF## LDAPv3# base <dc=mysite,dc=com> with scope subtree# filter: (objectclass=*)# requesting: ALL# # mysite.comdn: dc=mysite,dc=comobjectClass: topobjectClass: dcObjectobjectClass: organizationo: MySitedc: mysite # People, mysite.comdn: ou=People,dc=mysite,dc=comou: PeopleobjectClass: organizationalUnit # Group, mysite.comdn: ou=Group,dc=mysite,dc=comou: GroupobjectClass: organizationalUnit # firstgroup, Group, mysite.comdn: cn=firstgroup,ou=Group,dc=mysite,dc=comobjectClass: posixGroupobjectClass: topcn: onegroupuserPassword:: e2NyeXB0fXg=gidNumber: 1001memberUid: FirstUsermemberUid: SecondUser # secondgroup, Group, mysite.comdn: cn=secondgroup,ou=Group,dc=mysite,dc=comobjectClass: posixGroupobjectClass: topcn: twogroupuserPassword:: e2NyeXB0fXg=gidNumber: 1002memberUid: FirstUser # FirstUser, People, mysite.comdn: uid=FirstUser,ou=People,dc=mysite,dc=comuid: FirstUsercn: FirstUserobjectClass: accountobjectClass: posixAccountobjectClass: topobjectClass: shadowAccountshadowLastChange: 14250shadowMax: 99999shadowWarning: 7loginShell: /bin/bashuidNumber: 1014gidNumber: 1014homeDirectory: /home/FirstUsergecos: ,,,userPassword:: TXlQYXNzd29yZAo= # SecondUser, People, mysite.comdn: uid=SecondUser,ou=People,dc=mysite,dc=comuid: SecondUsercn: SecondUserobjectClass: accountobjectClass: posixAccountobjectClass: topobjectClass: shadowAccountshadowLastChange: 14002shadowMax: 99999shadowWarning: 7loginShell: /bin/bashuidNumber: 1005gidNumber: 1005homeDirectory: /home/SecondUsergecos: ,,,userPassword:: T3RoZXJQYXNzd29yZAo= After starting my OpenLDAP server, I load this information into the OpenLDAP server's database with ldapadd -D uid=root,ou=People,dc=mysite,dc=com -x -w ThePassword -f mysite.ldif Now assuming that LDAP authentication is enabled in the Linux server, and that PAM in this system will delegate its authentication to the OpenLDAP server above, the authentication works fine (assuming the correct password is entered, of course) but the groups information does not seem to be extracted correctly. After successfully logging in as users FirstUser, if from the command line I invoke groups FirstUser I get the following output: FirstUser : user onegroup onegroup twogroup twogroup I do not understand why 'onegroup' and 'twogroup' are repeated. For completeness, the /etc/nsswitch.conf file in the CentOS system contains (among other things) the following line: group: ldap [SUCCESS=return] files Any feedback on this issue will be welcome. It should be clear by now that I am not, by any means, an expert on things LDAP; my apologies if I am doing something stupid or misguided.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical