openldap-technical

openldap-technical@openldap.org

9 participants
9875 discussions

Assigning Groups to LDAP users
by pradyumna dash 06 Sep '11

06 Sep '11

Guys, I have a query, lets take a scenario : Assume we have 2 servers "Server1" and "Server2" and 2 groups "Admin" and "ITTech", What is needed is like say when a user "bob" logging in to "Server1" he will get the group "Admin", but when he logs in to "Server2" he will get group "ITTech". Also it may vary for different users like when "Kris" logs in to Server1 he may get a group called "ITTech" and when he logs in to "Server2" he will get some other group say "Security". Can it be possible by OpenLDAP ? If this is achieved then we are planning to have SUDO files based on the grooups. It would be great if you can provide me some pointers or how-to. Regards, Neo

6 6

Re: syncrepl giving error "CSN too old, ignoring " for detla replication
by Yuri Bank 05 Sep '11

05 Sep '11

Hmm. I thought you only needed NTP time sync with N-way and MMR. But not with single Provider. I guess I never noticed an issue with this since my servers run ntp ayways. On Sat, Sep 3, 2011 at 1:57 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Saturday, September 03, 2011 1:02 AM -0700 Yuri Bank < > yuribank(a)gmail.com> wrote: > > I've seen a very similar issue (ContextCSNs being newer on my consumers), >> and I believe it was fixed in OpenLDAP (2.4.26). Do the "CSN too old, >> ignoring" error messages spam endlessly in your consumer logs? >> >> As for your other questions. You only need a single accesslog, and the >> clocks on your consumer nodes do not need to be in synch with the >> Provider (in deltasync replication). >> > > Wrong. Your clocks should *always* be tightly in sync. Particularly with > the advent of delta-sync MMR in the next release. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

Slapd-meta stop at the first unreachable candidate
by Michel Gruau 05 Sep '11

05 Sep '11

Hello, It have a slapd-meta configuration as follows: database meta suffix dc=com uri ldap://server1:389/dc=suffix1,dc=com uri ldap://server2:389/dc=suffix2,dc=com uri ldap://server3:389/dc=suffix3,dc=com I performed numerous tests using "base=com" and changing the order of the above list of uri (in slapd.cnof) and I see that as soon as a candidate directory is unreachable, all other directories located below the directory in failure are not requested by the proxy. For instance, in example below: - if server2 is down, then server 3 is not requeted - if server1 is down, then none of the directories is requested. I have the felling this is a bug ... could you confirm ? FYI, I also tried the "'onerrr continue" config, but did not change annything Thanks in advance. Michel Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net

4 6

Re:Slapd-meta stop at the first unreachable candidate
by Michel Gruau 05 Sep '11

05 Sep '11

Below is a sample configuration allowing to reproduce the problem : Three openldap data instances configured as follows: include /opt/openldap/etc/openldap/schema/core.schema include /opt/openldap/etc/openldap/schema/cosine.schema include /opt/openldap/etc/openldap/schema/inetorgperson.schema include /opt/openldap/etc/openldap/schema/nis.schema include /opt/openldap/etc/openldap/schema/dyngroup.schema include /opt/openldap/etc/openldap/schema/misc.schema pidfile /opt/openldap/var/run/server1.pid argsfile /opt/openldap/var/run/server1.args loglevel stats database bdb suffix ou=orgunit,o=gouv,c=fr directory /opt/openldap/var/server1 Note: server1 is changed by server2 and server3 for other instances. Each instance contains the following data: (only 4 entries): dn: ou=orgunit,o=gouv,c=fr objectClass: top objectClass: organizationalUnit ou: orgunit dn: ou=dept1,ou=orgunit,o=gouv,c=fr ou: dept1 objectClass: top objectClass: organizationalUnit dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson mail: user11(a)server1.com cn: User 11 uid: user11 givenName: User sn: 11 dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson mail: user12(a)server1.com cn: User 12 uid: user12 givenName: User sn: 12 Note: user1x and dept1 are substituted in instances 2 and 3 by user2x, dept2, user3x,dept3. Data instances are launched using this command: /opt/openldap/libexec/slapd -n server1 -f /opt/openldap/etc/openldap/server1.conf -h ldap://0.0.0.0:1001/ /opt/openldap/libexec/slapd -n server2 -f /opt/openldap/etc/openldap/server2.conf -h ldap://0.0.0.0:1002/ /opt/openldap/libexec/slapd -n server3 -f /opt/openldap/etc/openldap/server3.conf -h ldap://0.0.0.0:1003/ Meta instance is configured as follows: include /opt/openldap/etc/openldap/schema/core.schema include /opt/openldap/etc/openldap/schema/cosine.schema include /opt/openldap/etc/openldap/schema/inetorgperson.schema include /opt/openldap/etc/openldap/schema/nis.schema include /opt/openldap/etc/openldap/schema/dyngroup.schema include /opt/openldap/etc/openldap/schema/anais.schema include /opt/openldap/etc/openldap/schema/misc.schema pidfile /opt/openldap/var/run/meta.pid argsfile /opt/openldap/var/run/meta.args database meta suffix ou=orgunit,o=gouv,c=fr uri ldap://localhost:1001/ou=dept1,ou=orgunit,o=gouv,c=fr #network-timeout 5 #timeout 3 uri ldap://localhost:1002/ou=dept2,ou=orgunit,o=gouv,c=fr #network-timeout 5 #timeout 4 uri ldap://localhost:1003/ou=dept3,ou=orgunit,o=gouv,c=fr #network-timeout 5 #timeout 4 and it is launched as follows: /opt/openldap/libexec/slapd -n meta -f /opt/openldap/etc/openldap/meta.conf -h ldap://0.0.0.0:1000/ -d 256 # test with the 3 servers up /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user31,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user32,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user21,ou=dept2,ou=orgunit,o=gouv,c=fr dn: uid=user22,ou=dept2,ou=orgunit,o=gouv,c=fr => entries from the three servers are returned # stop server 2 (kill -INT ...) and perfom a new search: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user31,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user32,ou=dept3,ou=orgunit,o=gouv,c=fr => looks good : entries from server1 and server 3 are returned Below are the meta instance logs: conn=1001 fd=9 ACCEPT from IP=172.30.8.13:55048 (IP=0.0.0.0:1000) conn=1001 op=0 BIND dn="" method=128 conn=1001 op=0 RESULT tag=97 err=0 text= conn=1001 op=1 SRCH base="ou=orgunit,o=gouv,c=fr" scope=2 deref=0 filter="(objectClass=person)" conn=1001 op=1 SRCH attr=dn conn=1001 op=1 meta_back_retry[1]: retrying URI="ldap://localhost:1002" DN="". conn=1001 op=1 meta_back_retry[1]: meta_back_single_dobind=52 conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=4 text= conn=1001 op=2 UNBIND conn=1001 fd=9 closed => looks good as nentries=4 # perform numerous new search without changing anything: [root@pp-ae2-proxy2 log]# /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: => nothing returned Below are the corresponding logs: conn=1002 fd=9 ACCEPT from IP=172.30.8.13:55049 (IP=0.0.0.0:1000) conn=1002 op=0 BIND dn="" method=128 conn=1002 op=0 RESULT tag=97 err=0 text= conn=1002 op=1 SRCH base="ou=orgunit,o=gouv,c=fr" scope=2 deref=0 filter="(objectClass=person)" conn=1002 op=1 SRCH attr=dn conn=1002 op=1 meta_search_dobind_init[1]: retrying URI="ldap://localhost:1002" DN="". conn=1002 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= conn=1002 op=2 UNBIND conn=1002 fd=9 closed => looks bad as nentries=0 => Only the first search after server2 stop is successfull. # new search but using server1 ou: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=dept1,ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr => looks good # same search as earlier i.e. using root node: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr => Looks good also. It looks like all is OK but only once a channel is opened to server1 using another manner # new search but using server3 base object: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=dept3,ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user31,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user32,ou=dept3,ou=orgunit,o=gouv,c=fr => looks good # new search but using slapd-meta base object: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user31,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user32,ou=dept3,ou=orgunit,o=gouv,c=fr => entries from server1 and server3 are returned => this confirms lookups in server1 and server3 are not performed until a channel is opened to both of them using their repective base object => another strange behavior : if search using server3 ou is performed before serach using server ou, then next search attempt using root node allows to retrieve entries from both server1 and server3 ... # new search after server2 restart: /opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: dn: uid=user11,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user12,ou=dept1,ou=orgunit,o=gouv,c=fr dn: uid=user21,ou=dept2,ou=orgunit,o=gouv,c=fr dn: uid=user31,ou=dept3,ou=orgunit,o=gouv,c=fr dn: uid=user22,ou=dept2,ou=orgunit,o=gouv,c=fr dn: uid=user32,ou=dept3,ou=orgunit,o=gouv,c=fr => good, all entries are returned # new search after meta instance restart while server2 is already stopped opt/openldap/bin/ldapsearch -LLL -x -H ldap://pp-ae2-proxy1.alize:1000 -b ou=orgunit,o=gouv,c=fr objectclass=person dn |grep dn: => unlike the previous test case (server2 stopped while meta instance is already running) we do not see the single successfull search. Then, behaviour is the same i.e. search on root node works again, but only once a search has been performed using ou=dept1 and ou=dept3. In addition, behaviour is slightly different adding the "conn-ttl" parameter set to 3 (3 seconds). I could expose it in a new post. Thanks for anyone who could help to identify whether it is a misconfiguration or a bug. Michel Gruau > Message du 19/08/11 13:13 > De : "Michel Gruau" > A : "openldap-technical openldap org" > Copie à : > Objet : Slapd-meta stop at the first unreachable candidate > > Hello, It have a slapd-meta configuration as follows: database meta suffix dc=com uri ldap://server1:389/dc=suffix1,dc=com uri ldap://server2:389/dc=suffix2,dc=com uri ldap://server3:389/dc=suffix3,dc=com I performed numerous tests using "base=com" and changing the order of the above list of uri (in slapd.cnof) and I see that as soon as a candidate directory is unreachable, all other directories located below the directory in failure are not requested by the proxy. For instance, in example below: - if server2 is down, then server 3 is not requeted - if server1 is down, then none of the directories is requested. I have the felling this is a bug ... could you confirm ? FYI, I also tried the "'onerrr continue" config, but did not change annything Thanks in advance. Michel > > Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net

1 0

RE: N-way multi master configuration issue
by Naga Chaitanya Palle 05 Sep '11

05 Sep '11

Hi, I was able to get the syncronization working between 2 providers. I had to remove data on both the servers and start from beginning. It worked. Now i am facing another issue. In case of single provider-client configuration, fot tls, i used to generate certificate on server and copy the same certificate to client for encrypted communication between provider and client. Now in case of N-way multimaster, i created server1 certificate and copied that certificate to server2 and vice versa. but there is no communication happening between the servers now. Can you please let me know how to use tls with N-way multimaster for N=2 and N>2. Thanks and Regards, Naga Chaitanya ________________________________________ From: Naga Chaitanya Palle Sent: Monday, August 29, 2011 1:37 PM To: Buchan Milne Cc: openldap-technical(a)openldap.org Subject: RE: N-way multi master configuration issue Hi Buchan, After making the changes are per your suggestions, I am still not able to read data between the servers. Also, I deleted DI data on server 2 and restarted to import data from server1 , but no use. Can you please check the slapd.conf files and suggest. Server 1 slapd.conf file # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/share/openldap2.4/schema/sudo.schema include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/nis.schema include /usr/share/openldap2.4/schema/misc.schema include /usr/share/openldap2.4/schema/openldap.schema include /usr/share/openldap2.4/schema/ppolicy.schema include /usr/share/openldap2.4/schema/corba.schema loglevel 296 # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args access to attrs=userPassword by self write by users read by anonymous auth #access to attrs=shadowLastChange # by self write # by * auth access to * by * read access to * by dn.base="cn=Manager,dc=comverse-in,dc=com" read by * break # Load dynamic backend modules: # modulepath /usr/lib/openldap # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCertificateFile /etc/pki/tls/certs/slapd.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem #TLSCipherSuite HIGH:MEDIUM:+SSLv2 #TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem #TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem #TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # ldbm and/or bdb database definitions ####################################################################### serverId 001 database bdb suffix "dc=comverse-in,dc=com" rootdn "cn=Manager,dc=comverse-in,dc=com" rootpw {SSHA}9tKeVZfgKFCfgIFQxXt5esH0HhQk1dIS # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap2.4 # Indices to maintain for this database #index objectClass eq,pres #index ou,cn,mail,surname,givenname eq,pres,sub #index uidNumber,gidNumber,loginShell eq,pres #index uid,memberUid eq,pres,sub #index nisMapName,nisMapEntry eq,pres,sub #index sudoUser eq index sudoUser eq index member eq index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub #index objectclass,entryCSN,entryUUID eq # Load dynamic backend modules: # modulepath /usr/lib/openldap modulepath /usr/lib/openldap2.4 # modules available in openldap-servers-overlays RPM package: # moduleload accesslog.la # moduleload auditlog.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload smbk5pwd.la moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # modules available in openldap-servers-sql RPM package: # moduleload back_sql.la syncrepl rid=123 provider=ldap://devonly144.comverse-in.com type=refreshAndPersist interval=00:00:01:00 searchbase="dc=comverse-in,dc=com" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="cn=Manager,dc=comverse-in,dc=com" credentials=sonora index objectClass,entryCSN,entryUUID eq mirrormode true overlay syncprov syncprov-checkpoint 100 10 overlay ppolicy ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com" ppolicy_hash_cleartext ppolicy_use_lockout #SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM #replogfile /var/lib/ldap/openldap-master-replog #replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical Server2 slapd.conf file # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/share/openldap2.4/schema/sudo.schema include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/nis.schema include /usr/share/openldap2.4/schema/misc.schema include /usr/share/openldap2.4/schema/openldap.schema include /usr/share/openldap2.4/schema/ppolicy.schema include /usr/share/openldap2.4/schema/corba.schema loglevel 296 # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args access to attrs=userPassword by self write by users read by anonymous auth #access to attrs=shadowLastChange # by self write # by * auth access to * by * read access to * by dn.base="cn=Manager,dc=comverse-in,dc=com" read by * break # Load dynamic backend modules: # modulepath /usr/lib/openldap # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCertificateFile /etc/pki/tls/certs/slapd.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem #TLSCipherSuite HIGH:MEDIUM:+SSLv2 #TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem #TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem #TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # ldbm and/or bdb database definitions ####################################################################### serverId 002 #database bdb database bdb #suffix "dc=comverse-in,dc=com" suffix "dc=comverse-in,dc=com" #rootdn "cn=Manager,dc=comverse-in,dc=com" rootdn "cn=Manager,dc=comverse-in,dc=com" rootpw {SSHA}4qLml3DcOyfwiKlN/garIms4a8fmsNkx #rootpw sonora # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap2.4 # Indices to maintain for this database #index objectClass eq,pres #index ou,cn,mail,surname,givenname eq,pres,sub #index uidNumber,gidNumber,loginShell eq,pres #index uid,memberUid eq,pres,sub #index nisMapName,nisMapEntry eq,pres,sub #index sudoUser eq index sudoUser eq index member eq index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub #index objectclass,entryCSN,entryUUID eq # Load dynamic backend modules: # modulepath /usr/lib/openldap modulepath /usr/lib/openldap2.4 # modules available in openldap-servers-overlays RPM package: # moduleload accesslog.la # moduleload auditlog.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload smbk5pwd.la moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # modules available in openldap-servers-sql RPM package: # moduleload back_sql.la overlay ppolicy ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com" ppolicy_hash_cleartext ppolicy_use_lockout #SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM #replogfile /var/lib/ldap/openldap-master-replog #replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical binddn="cn=Manager,dc=comverse-in,dc=com" bindmethod=simple credentials=sonora #serverId 2 syncrepl rid=124 provider=ldap://uplite98.comverse-in.com type=refreshAndPersist interval=00:00:01:00 searchbase="dc=comverse-in,dc=com" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="cn=Manager,dc=comverse-in,dc=com" credentials=sonora #updateref ldap://uplite98.comverse-in.com index objectClass,entryCSN,entryUUID eq mirrormode true overlay syncprov syncprov-checkpoint 100 10 Thanks and Regards, Naga Chaitanya -----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Friday, August 26, 2011 7:15 PM To: Naga Chaitanya Palle Cc: openldap-technical(a)openldap.org Subject: Re: N-way multi master configuration issue On Friday, 26 August 2011 15:28:13 Naga Chaitanya Palle wrote: > Hi buchan, > > My server 1 is uplite98.comverse-in.com. In its slapd.conf, I have syncrepl > pointing to server 2 devonly144.comverse-in.com and vice versa for > server2. Then your serverid (and, it should actually be serverId) is wrong: > > serverid 124 ldap://devonly144.comverse-in.com > > syncrepl rid=124 > > > > provider=ldap://devonly144.comverse-in.com:389 The URI form of serverId is useful if you have the same configuration on all your masters, in which case the listening address of your server must match one of the URIs. You may want to use this form for now: serverId 1 If your serverId's weren't correct (check the contextCSNs), you should probably re-import an export of one server on the other one. > I did not exactly understand what you indicated. > Can you please be more specific about what changes needs to be done in the > slapd.conf file? In a multi-master setup, each server should be replicating off *all* servers, including itself. > Thanks and Regards, > Naga Chaitanya > > -----Original Message----- > From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] > Sent: Friday, August 26, 2011 6:56 PM > To: openldap-technical(a)openldap.org > Cc: Naga Chaitanya Palle > Subject: Re: N-way multi master configuration issue > > On Friday, 26 August 2011 12:56:38 Naga Chaitanya Palle wrote: > > Hi, > > > > I am trying to set up N-way multimaster configuration using syncrepl on > > openldap2.4 for RHEL 5.4 > > > > Currently I am using two masters for testing. > > > > The slapd.conf on server1 is > > moduleload syncprov.la > > serverid 124 ldap://devonly144.comverse-in.com > > syncrepl rid=124 > > > > provider=ldap://devonly144.comverse-in.com:389 > > type=refreshAndPersist > > interval=00:00:01:00 > > searchbase="dc=comverse-in,dc=com" > > filter="(objectClass=*)" > > scope=sub > > attrs="*" > > schemachecking=off > > bindmethod=simple > > binddn="cn=Manager,dc=comverse-in,dc=com" > > credentials=sonora > > > > index objectClass,entryCSN,entryUUID eq > > mirrormode true > > > > overlay syncprov > > syncprov-checkpoint 100 10 > > > > > > The slapd.conf on server2 is > > moduleload syncprov.la > > serverid 123 ldap://uplite98.comverse-in.com > > syncrepl rid=123 > > > > provider=ldap://uplite98.comverse-in.com:389 > > type=refreshAndPersist > > interval=00:00:01:00 > > searchbase="dc=comverse-in,dc=com" > > filter="(objectClass=*)" > > scope=sub > > attrs="*" > > schemachecking=off > > bindmethod=simple > > binddn="cn=Manager,dc=comverse-in,dc=com" > > credentials=sonora > > > > index objectClass,entryCSN,entryUUID eq > > mirrormode true > > > > overlay syncprov > > syncprov-checkpoint 100 10 > > > > But there is no data synchronization happening between the severs. > > Of course not, you have configured each server only to replicate from > itself. > > > When I added test3 user on server1, it is not reflecting on server 2. > > Same way when I added test4 user on server2 it is not reflecting on > > server1. > > > > Please let me know what is missing in this configuration. > > syncrepl statements pointing to the other master. > > Regards, > Buchan > > > > > =========================================================================== > ==== Please refer to http://www.aricent.com/legal/email_disclaimer.html for > important disclosures regarding this electronic communication. > ========================================================================== > ===== =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===============================================================================

4 5

OpenLDAP proxy, identity assertion and suffix massage
by Clément OUDOT 05 Sep '11

05 Sep '11

Hello, I am using OpenLDAP 2.4.26 on GNU/Linux. I would like to configure a simple proxy with identity assertion and suffix massage and assert identity for the rootdn of my LDAP backend, to match the rootdn of the proxied backend (on port 390). Here is my configuration : ------------ database ldap suffix "ou=am,dc=local" rootdn "cn=manager,ou=am,dc=local" rootpw secretproxy uri ldap://127.0.0.1:390 idassert-bind bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials="secret" mode=none idassert-authzFrom "dn.exact:cn=manager,ou=am,dc=local" overlay rwm rwm-suffixmassage "ou=am,dc=local" "dc=example,dc=com" ------------ When I try to authenticate with "cn=manager,ou=am,dc=local" on the proxy, the bind is forwarded to the proxied directory directly, as "cn=manager,dc=example,dc=com". It seems the rwm overlay has done the substitution, so the idassert-authzFrom does not match. This ended with an LDAP error 48, as we can see here: ------------ >>> dnPrettyNormal: <cn=manager,ou=am,dc=local> => ldap_bv2dn(cn=manager,ou=am,dc=local,0) <= ldap_bv2dn(cn=manager,ou=am,dc=local)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,ou=am,dc=local)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,ou=am,dc=local)=0 <<< dnPrettyNormal: <cn=manager,ou=am,dc=local>, <cn=manager,ou=am,dc=local> conn=1001 op=0 BIND dn="cn=manager,ou=am,dc=local" method=128 do_bind: version=3 dn="cn=manager,ou=am,dc=local" method=128 ==> rewrite_context_apply [depth=1] string='cn=manager,ou=am,dc=local' ==> rewrite_rule_apply rule='((.+),)?ou=am,[ ]?dc=local$' string='cn=manager,ou=am,dc=local' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'cn=manager,dc=example,dc=com'} [rw] bindDN: "cn=manager,ou=am,dc=local" -> "cn=manager,dc=example,dc=com" >>> dnPrettyNormal: <cn=manager,dc=example,dc=com> => ldap_bv2dn(cn=manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: <cn=manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> ===>slap_sasl_match: comparing DN cn=manager,dc=example,dc=com to rule dn:cn=manager,ou=am,dc=local slap_parseURI: parsing dn:cn=manager,ou=am,dc=local <===slap_sasl_match: comparison returned 48 send_ldap_result: conn=1001 op=0 p=3 send_ldap_result: err=48 matched="" text="" send_ldap_response: msgid=1 tag=97 err=48 ------------ Do you have any suggestion for using the idassert-authzFrom parameter with the suffixmassage? Thanks for your help, Clément.

2 2

how to access 'description' attribute from LDAP server??
by vijay s sheelavantar 04 Sep '11

04 Sep '11

Hi, Please let me know how can i access 'description' attribute stored in LDAP server from LDAP  client(pam_ldap,nss_ldap). Thank you. Regards, Vijay S.

1 0

Re: LDAP authentication of unregistered user at client side.
by vijay s sheelavantar 04 Sep '11

04 Sep '11

Thank you very much Buchan. There was some problem with /etc/nsswitch.conf  file.I changed this configuration using "env LANG=C authconfig-tui" command and selected LDAP option. This will change the nsswitch.conf file properly. Thank you.

1 0

RE : Slapd-meta stop at the first unreachable candidate
by Rodrigo Souza dos Santos 04 Sep '11

04 Sep '11

2 1

s_client working against 636 but not 389
by Nate Marks 04 Sep '11

04 Sep '11

[root@ldap01 cacerts]# netstat -panv | grep slap ... tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 3220/slapd tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 3220/slapd [root@ldap01 cacerts]# grep TL /etc/openldap/slapd.conf # The next three lines allow use of TLS for encrypting connections using a # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCACertificateFile /etc/pki/CA/cacert.pem TLSCACertificateFile /etc/pki/tls/certs/cacert.pem # TLSCertificateFile /etc/pki/tls/certs/slapd.pem TLSCertificateFile /etc/openldap/cacerts/ldap01.infra.ops.hcs.cert.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem TLSCertificateKeyFile /etc/openldap/cacerts/ldap01.infra.ops.hcs.key.pem ***COMMENT: This command seems a little slow, but it succeeds *** [root@ldap01 cacerts]# openssl s_client -CAfile /etc/pki/tls/certs/cacert.pem -connect 10.60.1.57:636 CONNECTED(00000003) depth=1 /C=US/ST=MA/O=NWN Corporation/OU=hcs/CN=ca.ops.hcs/emailAddress=ca(a)ops.hcs verify return:1 depth=0 /C=US/ST=MA/L=Waltham/O=NWN Corporation/OU=hcs/CN=ldap01.infra.ops.hcs/emailAddress=support(a)nwnit.com verify return:1 --- Certificate chain 0 s:/C=US/ST=MA/L=Waltham/O=NWN Corporation/OU=hcs/CN=ldap01.infra.ops.hcs/emailAddress=support(a)nwnit.com i:/C=US/ST=MA/O=NWN Corporation/OU=hcs/CN=ca.ops.hcs/emailAddress=ca(a)ops.hcs 1 s:/C=US/ST=MA/O=NWN Corporation/OU=hcs/CN=ca.ops.hcs/emailAddress=ca(a)ops.hcs i:/C=US/ST=MA/O=NWN Corporation/OU=hcs/CN=ca.ops.hcs/emailAddress=ca(a)ops.hcs --- Server certificate -----BEGIN CERTIFICATE----- MIIDATCCAmqgAwIBAgIJANZXaZL0G6eAMA0GCSqGSIb3DQEBBQUAMHIxCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJNQTEYMBYGA1UEChMPTldOIENvcnBvcmF0aW9uMQww CgYDVQQLEwNoY3MxEzARBgNVBAMTCmNhLm9wcy5oY3MxGTAXBgkqhkiG9w0BCQEW CmNhQG9wcy5oY3MwHhcNMTEwODMxMDkwOTEyWhcNMTIwODMwMDkwOTEyWjCBlTEL MAkGA1UEBhMCVVMxCzAJBgNVBAgTAk1BMRAwDgYDVQQHEwdXYWx0aGFtMRgwFgYD VQQKEw9OV04gQ29ycG9yYXRpb24xDDAKBgNVBAsTA2hjczEdMBsGA1UEAxMUbGRh cDAxLmluZnJhLm9wcy5oY3MxIDAeBgkqhkiG9w0BCQEWEXN1cHBvcnRAbnduaXQu Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDV/XlgAuwbisnokbCXUvXz M5SXTeG6D697Sgh7ggcvdwVprKlfFWCLu3RcSkBbJ69bTDgRQS6qlplUm9kB44XB Ej+8w+YVvTGxZWYIxyr3u2SKYFrIVj4DpeCZyYrgFds9JK9YGh6cDj57PGXbw9aK ApE1SKPNx2SCkMy9WSzLOwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUdO79 lD14LPMt0cviy00Bi/zoVz8wHwYDVR0jBBgwFoAURUA5pElJg/XvOcDIdWZ6W+EN 54IwDQYJKoZIhvcNAQEFBQADgYEANOSnNbRW+US5xf4fQrz0M765wuOKjvuWK4yG K5GcWPv8zAM9bEf0Ju9A9RiMzxwDfQndRQ84fTELXKQeHFYa0ELse8G4ZdxRyEtN GzigGoPQYqtofW3N2mIRb85RntHoIBwfrhnogsY2UXssIWc/8CGgwp4OjtYhiXMU JtHLAms= -----END CERTIFICATE----- subject=/C=US/ST=MA/L=Waltham/O=NWN Corporation/OU=hcs/CN=ldap01.infra.ops.hcs/emailAddress=support(a)nwnit.com issuer=/C=US/ST=MA/O=NWN Corporation/OU=hcs/CN=ca.ops.hcs/emailAddress=ca(a)ops.hcs --- No client certificate CA names sent --- SSL handshake has read 1775 bytes and written 319 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: 1F3B030DD062E3EFC3E143DF978A622DD8B0E2167331EAC45C307C8997F59BC3 Session-ID-ctx: Master-Key: 834A1CF62289DB6C4367109B9EF2172796A4AF403F4FE040C4EDDC48ED722437E96717A860038A70323DFFD1EDE3562D Key-Arg : None Krb5 Principal: None Start Time: 1315065479 Timeout : 300 (sec) Verify return code: 0 (ok) --- *** COMMENT: This obviosly doesn't *** [root@ldap01 cacerts]# openssl s_client -CAfile /etc/pki/tls/certs/cacert.pem -connect 10.60.1.57:389 CONNECTED(00000003) 4392:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: [root@ldap01 cacerts]# The only thing I could think of is a timeout difference between ssl and tls, iun which case I'll be fine wheh I figure out why it's slow, but I'd like to validate that before moving on to the slowness problem. ANyone have ideas?

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