openldap-technical

openldap-technical@openldap.org

13 participants
9906 discussions

Cyrus IMAPD + virtual domains + SASL + OpenLDAP ldapdb
by Nels Lindquist 21 Feb '14

21 Feb '14

I'm attempting to configure Cyrus IMAPD with ldapdb for SASL authentication. As I'm using virtual domains, I need users to be able to authenticate using their e-mail addresses, or just a bare userid for the default domain. I'm having some trouble getting everything working[1]. Based on this documentation extract from Cyrus SASL, I've been primarily focussing on the OpenLDAP configuration: "Unlike other LDAP-enabled plugins for other services that are common on the web, this plugin does not require you to configure DN search patterns to map usernames to LDAP DNs. This plugin requires SASL name mapping to be configured on the target slapd. This approach keeps the LDAP-specific configuration details in one place, the slapd.conf, and makes the configuration of remote services much simpler." I've set up a number of olcAuthzRegexp entries similar to (from the OpenLDAP 2.4 admin guide): "A more complex site might have several realms in use, each mapping to a different subtree in the directory. These can be handled with statements of the form: # Match Engineering realm authz-regexp uid=([^,]*),cn=engineering.example.com,cn=digest-md5,cn=auth ldap:///dc=eng,dc=example,dc=com??one?(&(uid=$1)(objectClass=person)) # Match Accounting realm authz-regexp uid=([^,].*),cn=accounting.example.com,cn=digest-md5,cn=auth ldap:///dc=accounting,dc=example,dc=com??one?(&(uid=$1)(objectClass=person)) # Default realm is customers.example.com authz-regexp uid=([^,]*),cn=digest-md5,cn=auth ldap:///dc=customers,dc=example,dc=com??one?(&(uid=$1)(objectClass=person))" However, from what I can determine I'm not getting any realm component in the searches coming through. The "default" realm configuration works when I use a bare userid to authenticate, but when using a full e-mail address, that comes through as "uid=example(a)example.com,cn=[authmech],cn=auth". That said, I haven't found a LogLevel which includes AuthzRegexp processing; I've tried various settings, but the closest I've come is logging the resulting bind requests (eg. BIND dn="uid=example,ou=people,dc=example,dc=com" mech=DIGEST-MD5 sasl_ssf=128 ssf=128). So my question is, how is the realm determined in such a scenario? Do I need to design olcAuththzRegexp entries to determine the realm based on the e-mail address supplied? If so, how does that information get passed back to Cyrus IMAPD so that the correct virtual domain is selected? Is there an appropriate olcLogLevel to see detailed olcAuthzRegexp processing? I'd be grateful for any suggestions or references to documentation, etc. I've done some searching of the mailing list archives to little avail. In case it matters, this is on CentOS 6.5 (x86_64) with stock OpenLDAP 2.4.23 and Cyrus SASL 2.1.23 packages, plus Cyrus IMAPD 2.4.17 built from Simon Matter's SRPM. [1] I *am* able to get authentication + virtual domains working with saslauthd, but I'd like to be able to support non-plaintext auth mechanisms. ---- Nels Lindquist

3 2

RE: Syncrepl and mmr
by Quanah Gibson-Mount 20 Feb '14

20 Feb '14

Hi John, SIDs (server IDs) must be unique across servers. RIDs (replication IDs) must be unique inside a single server. So the answer to your question is essentially "no". If you email me your full cn=config db bits from both servers (minus passwords), there's some cleanup on them I can send back. The serverID: 1 <URI> bit is only necessary if you are doing cn=config replication, which you are not doing. If you are going to use the <#> <URI> form, then the <URI> must EXACTLY MATCH the arguments slapd is being started with. Personally, since I do not do cn=config replication, and the URIs are customizable by customers, I go with the much simpler: olcServerID: <#> form. Then each server only has a single value for olcServerID, which is its specific serverID. This way I never have to worry that MMR replication is going to get mesed up because of URI changes. --Quanah --On Tuesday, February 18, 2014 10:09 AM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > All, > > The long weekend didn't help...still at a loss. Question... > > If the olcServerIDs look like, on all three servers: > > olcServerID: 1 ldap://mm-server1.example.ldap > olcServerID: 2 ldap://mm-server2.example.ldap > olcServerID: 3 ldap://mm-server3.example.ldap > > Should the Replica IDs (rid) in the olcSycnrepl directive be: > > olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap > bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" > credentials=<password> interval=01:00:00:00 > searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on > type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" > syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002 > provider=mm-server2.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap > bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" > credentials=<password> interval=01:00:00:00 > searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on > type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" > syncdata=accesslog starttls=no > > OR > > olcSyncrepl: {0} rid=1 provider=mm-server1.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > olcSyncrepl: {1} rid=2 provider=mm-server2.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > olcSyncrepl: {0} rid=3 provider=mm-server3.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > > OR > > Does it matter? > > Also, should the all three olcSycrepl directives be loaded on all three > servers so they look identical. What I mean by that is should each > Server "replicate" to itself? There is confusion on this matter. I > asked Quanah that back in late January, and he stated that the system > knows about itself so it knows what to ignore. Then last week, he asked > why I had the master replicating to itself. > > Also, since I have refreshAndPersist configured do I need an interval as > well? > > Thanks in advance, > > John > > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, > John - 0442 - MITLL Sent: Friday, February 14, 2014 4:28 PM > To: Quanah Gibson-Mount; openldap-technical(a)openldap.org > Subject: RE: Syncrepl and mmr > > All, > > I just created an mm-server3, using the config_dbase and main_dbase from > mm-server2 -- copied the ldif's I created from mm-server2 then ran > slapadd. > > On mm-server3: > olcServerID: 1 ldap://mm-server1.example.ldap > olcServerID: 2 ldap://mm-server2.example.ldap > olcServerID: 3 ldap://mm-server3.example.ldap > > olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap > bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" > credentials=<password> interval=01:00:00:00 > searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on > type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" > syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002 > provider=mm-server2.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap > bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" > credentials=<password> interval=01:00:00:00 > searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on > type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" > syncdata=accesslog starttls=no > > Started slapd, no errors. It immediately sync'd up with mm-server1! > Changes that I made on mm-server1 days ago which have never replicated > over to mm-server2...replicated to mm-server3 immediately on startup. > > I had not even got around to adding mm-server3 to mm-server1 (or > mm-server2) yet. > > The olcServerIDs and olcSyncrepl on both mm-server1 and 2 show: > olcServerID: 1 ldap://mm-server1.example.ldap > olcServerID: 2 ldap://mm-server2.example.ldap > > olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap > bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" > credentials=<password> interval=01:00:00:00 > searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on > type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" > syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002 > provider=mm-server2.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > > So...now, I am at even more of a loss. Why would mm-server1 be > replicating to mm-server3 and not 2? When the configs are the same > between mm-server2 and 3??? > > > > Thanks in advance... > John > > > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, > John - 0442 - MITLL Sent: Friday, February 14, 2014 1:34 PM > To: Quanah Gibson-Mount; openldap-technical(a)openldap.org > Subject: RE: Syncrepl and mmr > > All, > > If I went off the beaten' path...where did I go wrong? (my config and > error messages are in a previous posting) > > Thanks in advance, > John > > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, > John - 0442 - MITLL Sent: Friday, February 14, 2014 8:40 AM > To: Quanah Gibson-Mount; openldap-technical(a)openldap.org > Subject: RE: Syncrepl and mmr > > Thanks Quanah, > > A few weeks back I asked that question (on 1/30): >> All Masters in the chain have the olcServerID's and olcSynRepl for >> itself and its partner? I can understand having each knowing about >> the others but why itself? It's replicating to itself? > -You replied > -It knows about itself so it knows what to ignore. > > Even in the Admin Guide is specifies setting it up that way...each server > has all the others and itself listed. I was following the procedures > delineated in the Admin Guide and in the man-pages (including how I > understood what was put out on the board): From the Admin Guide: > 8.3.3. N-Way Multi-Master > > For the following example we will be using 3 Master nodes. Keeping in > line with test050-syncrepl-multimaster of the OpenLDAP test suite, we > will be configuring slapd(8) via cn=config > > This sets up the config database: > > dn: cn=config > objectClass: olcGlobal > cn: config > olcServerID: 1 > > dn: olcDatabase={0}config,cn=config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcRootPW: secret > > second and third servers will have a different olcServerID obviously: > > dn: cn=config > objectClass: olcGlobal > cn: config > olcServerID: 2 > > dn: olcDatabase={0}config,cn=config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcRootPW: secret > > This sets up syncrepl as a provider (since these are all masters): > > dn: cn=module,cn=config > objectClass: olcModuleList > cn: module > olcModulePath: /usr/local/libexec/openldap > olcModuleLoad: syncprov.la > > Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc. > with your actual ldap urls): > > dn: cn=config > changetype: modify > replace: olcServerID > olcServerID: 1 $URI1 > olcServerID: 2 $URI2 > olcServerID: 3 $URI3 > > dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config > changetype: add > objectClass: olcOverlayConfig > objectClass: olcSyncProvConfig > olcOverlay: syncprov > > dn: olcDatabase={0}config,cn=config > changetype: modify > add: olcSyncRepl > olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" > bindmethod=simple credentials=secret searchbase="cn=config" > type=refreshAndPersist retry="5 5 300 5" timeout=1 > olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" > bindmethod=simple credentials=secret searchbase="cn=config" > type=refreshAndPersist retry="5 5 300 5" timeout=1 > olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config" > bindmethod=simple credentials=secret searchbase="cn=config" > type=refreshAndPersist retry="5 5 300 5" timeout=1 > - > add: olcMirrorMode > olcMirrorMode: TRUE > > I followed what is put in the Admin Guide, etc... > > Thanks > > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah > Gibson-Mount Sent: Thursday, February 13, 2014 1:57 PM > To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org > Subject: Re: Syncrepl and mmr > > --On Thursday, February 13, 2014 10:54 AM -0500 "Borresen, John - 0442 - > MITLL" <John.Borresen(a)ll.mit.edu> wrote: > >> All, > > Your configuration is very confused. Why do you have the master > replicate to itself, for example? > > --Quanah > > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > > -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

3 5

AttributeDescription contains inappropriate characters
by Kamran Khan 20 Feb '14

20 Feb '14

Hi All, I'm a bit new to OpenLDAP, and I'm not quite sure what went wrong. I installed OpenLDAP because it was a prerequisite of Moab. After installing OpenLDAP and Moab yesterday, I had everything working just fine. I rebooted the cluster, and now OpenLDAP is not happy. ============================================================ [root@USDTWCLUS01 ~]# service slapd start Checking configuration files for slapd: [FAILED] <= str2entry: str2ad(o): AttributeDescription contains inappropriate characters slaptest: bad configuration file! ============================================================ I understand that something in my configuration must be messed up, but I am really unsure where there error is occuring. I'm unsure where my 'str2entry's are. Any help is greatly appreciated. Like I said, I had it working just fine yesterday, and after a reboot it didn't like something. Thanks. -- Kamran Khan PSSC Labs HPC Software Technical Engineer

3 4

openldap 2.4.33 configure problem - could not locate TLS/ssl package.
by xiaoming zhao 20 Feb '14

20 Feb '14

All, can someone help me out? When building openldap 2.4.33, I got the following error "Could not locate TLS/SSL package". did I missed something in openssl? how to fix it? Thanks in advance for your support! checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_library_init in -lssl... no checking for ssl3_accept in -lssl... no checking gnutls/gnutls.h usability... no checking gnutls/gnutls.h presence... no checking for gnutls/gnutls.h... no checking nssutil.h usability... no checking nssutil.h presence... no checking for nssutil.h... no configure: WARNING: Could not locate TLS/SSL package configure: WARNING: TLS data protection not supported Thanks, Eric.

3 2

Re: LDAP via TLS
by Tim Dunphy 20 Feb '14

20 Feb '14

Hey Dan, Those docs you pointed me to worked beautifully! And thanks for the examples from your own config. I've used those too. Worked great! Thanks again. Although I do also apprecaite the advice to read the official docs. Good advice, however the ones that I've been pointed to worked well for me. I'll read the official docs for a fuller understanding tho. Tim On Wed, Feb 19, 2014 at 2:08 PM, Dan Pritts <danno(a)umich.edu> wrote: > I have simply > > TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt > TLSCertificateFile /etc/pki/tls/certs/ldap.icpsr.umich.edu.crt > TLSCertificateKeyFile /etc/pki/tls/private/ldap.icpsr.umich.edu.key > > > in my slapd.conf. CACertificateFile is almost certainly not required > for a server cert. > > > Maybe you are running into an oddity of the cn=config? Have you tried > just opening up the permissions to make sure the files are world readable? > no selinux involved? > > > > Folks on the list will probably yell at you to use the current version > rather than the centos packages. > > If you look through the archives for the last few weeks, you will find a > pointer to a site that has rpm builds of current openldap. > > Tim Dunphy <bluethundr(a)gmail.com> > February 19, 2014 at 1:35 PM > Hey ldap folks! > > I've attempted to add TLS capabilities to my newly created LDAP server > using the following document: > > http://www.server-world.info/en/note?os=CentOS_6&p=ldap&f=3 > > This is how my cert files are looking in terms of ownership and > permissions: > > [root@puppet:~] #ls -l /etc/pki/tls/*/* | grep ldap > -r-------- 1 ldap root 1241 Feb 19 13:06 /etc/pki/tls/certs/ldap.crt > -r-------- 1 ldap root 1021 Feb 19 13:05 /etc/pki/tls/misc/ldap.csr > -r-------- 1 ldap root 1679 Feb 19 13:01 /etc/pki/tls/private/ldap.key > > I got to the point where I'm attempting to add the configuration > parameters to my ldap setup like so: > > [root@puppet:~] #ldapmodify -Y EXTERNAL -H ldapi:/// > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > dn: cn=config > add: olcTLSCertificateFile > olcTLSCertificateFile: /etc/pki/tls/certs/ldap.crt > - > add: olcTLSCertificateKeyFile > olcTLSCertificateKeyFile: /etc/pki/tls/private/ldap.key > modifying entry "cn=config" > ldap_modify: Inappropriate matching (18) > additional info: modify/add: olcTLSCertificateFile: no equality > matching rule > > > These are the package version numbers I have installed via yum on CentOS > 6.5: > > openldap-2.4.23-34.el6_5.1.x86_64 > openldap-devel-2.4.23-34.el6_5.1.x86_64 > openldap-servers-2.4.23-34.el6_5.1.x86_64 > openldap-clients-2.4.23-34.el6_5.1.x86_64 > > Can anyone offer some wisdom as to why this error is happening? Or perhaps > offer some better documentation on how to enable the TLS abilities of > openldap? > > Thanks > Tim > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > > -- > Dan Pritts > ICPSR Computing & Network Services > University of Michigan > +1 (734)615-7362 > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

3 2

trouble with acls
by brendan kearney 19 Feb '14

19 Feb '14

list, i am running the below version: @(#) $OpenLDAP: slapd 2.4.26 (Jun 27 2012 15:27:46) $ mockbuild@x86-16.phx2.fedoraproject.org:/builddir/build/BUILD/openldap-2.4.26/openldap-2.4.26/build-servers/servers/slapd i have the below acls: olcAccess: {0}to attrs=userPassword,shadowLastChange by anonymous auth by * none olcAccess: {1}to attrs=loginShell by self write by * none olcAccess: {2}to dn.base="" by * read olcAccess: {3}to dn.subtree="dc=bpk2,dc=com" by dn="cn=adm-srv,dc=bpk2,dc=com" write by dn="cn=kdc-srv,dc=bpk2,dc=com" read by * none olcAccess: {4}to dn.subtree="dc=bpk2,dc=com" by set="[cn=ldapAdmins,ou=Groups, dc=bpk2,dc=com]/memberUid & user/uid" write by set="[cn=users,ou=Groups,dc=bp k2,dc=com]/memberUid & user/uid" read by * none i issue the below search query: ldapsearch -h ldap1 -Y GSSAPI -b 'dc=bpk2,dc=com' -s sub '(objectclass=ipHost)' and get the below output: SASL/GSSAPI authentication started SASL username: brendan(a)BPK2.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=bpk2,dc=com> with scope subtree # filter: (objectclass=ipHost) # requesting: ALL # # search result search: 4 result: 32 No such object # numResponses: 1 the logs for acls show: 2014-02-19T18:41:17.562950-05:00 server slapd[2033]: => access_allowed: search access to "dc=bpk2,dc=com" "entry" requested 2014-02-19T18:41:17.562976-05:00 server slapd[2033]: => dn: [3] 2014-02-19T18:41:17.562986-05:00 server slapd[2033]: => dn: [4] dc=bpk2,dc=com 2014-02-19T18:41:17.562996-05:00 server slapd[2033]: => acl_get: [4] matched 2014-02-19T18:41:17.563005-05:00 server slapd[2033]: => acl_get: [4] attr entry 2014-02-19T18:41:17.563014-05:00 server slapd[2033]: => acl_mask: access to entry "dc=bpk2,dc=com", attr "entry" requested 2014-02-19T18:41:17.563024-05:00 server slapd[2033]: => acl_mask: to all values by "uid=brendan,ou=users,dc=bpk2,dc=com", (=0) 2014-02-19T18:41:17.563034-05:00 server slapd[2033]: <= check a_dn_pat: cn=adm-srv,dc=bpk2,dc=com 2014-02-19T18:41:17.563043-05:00 server slapd[2033]: <= check a_dn_pat: cn=kdc-srv,dc=bpk2,dc=com 2014-02-19T18:41:17.563052-05:00 server slapd[2033]: <= check a_dn_pat: * 2014-02-19T18:41:17.563290-05:00 server slapd[2033]: <= acl_mask: [3] applying none(=0) (stop) 2014-02-19T18:41:17.563327-05:00 server slapd[2033]: <= acl_mask: [3] mask: none(=0) 2014-02-19T18:41:17.563336-05:00 server slapd[2033]: => slap_access_allowed: search access denied by none(=0) 2014-02-19T18:41:17.563344-05:00 server slapd[2033]: => access_allowed: no more rules i am trying to figure out why i keep getting denied. i tried slapacl: sudo slapacl -F /etc/openldap/slapd.d -v -U brendan(a)BPK2.COM -b "dc=bpk2,dc=com" "dc/read:bpk2,dc=com" this shows a weird user dn and an error: authcDN: "uid=brendan(a)bpk2.com,ou=users,dc=bpk2,dc=com" read access to dc=bpk2,dc=com: DENIED are my olcRegExp statements wrong: olcAuthzRegexp: {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid=$1,ou=Users,dc=bpk2,dc=com olcAuthzRegexp: {1}uid=([^,]*),cn=gssapi,cn=auth uid=$1,ou=Users,dc=bpk2,dc=com where am i not going about this correctly? any help would be appreciated. brendan kearney

1 0

LDAP via TLS
by Tim Dunphy 19 Feb '14

19 Feb '14

Hey ldap folks! I've attempted to add TLS capabilities to my newly created LDAP server using the following document: http://www.server-world.info/en/note?os=CentOS_6&p=ldap&f=3 This is how my cert files are looking in terms of ownership and permissions: [root@puppet:~] #ls -l /etc/pki/tls/*/* | grep ldap -r-------- 1 ldap root 1241 Feb 19 13:06 /etc/pki/tls/certs/ldap.crt -r-------- 1 ldap root 1021 Feb 19 13:05 /etc/pki/tls/misc/ldap.csr -r-------- 1 ldap root 1679 Feb 19 13:01 /etc/pki/tls/private/ldap.key I got to the point where I'm attempting to add the configuration parameters to my ldap setup like so: [root@puppet:~] #ldapmodify -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=config add: olcTLSCertificateFile olcTLSCertificateFile: /etc/pki/tls/certs/ldap.crt - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/pki/tls/private/ldap.key modifying entry "cn=config" ldap_modify: Inappropriate matching (18) additional info: modify/add: olcTLSCertificateFile: no equality matching rule These are the package version numbers I have installed via yum on CentOS 6.5: openldap-2.4.23-34.el6_5.1.x86_64 openldap-devel-2.4.23-34.el6_5.1.x86_64 openldap-servers-2.4.23-34.el6_5.1.x86_64 openldap-clients-2.4.23-34.el6_5.1.x86_64 Can anyone offer some wisdom as to why this error is happening? Or perhaps offer some better documentation on how to enable the TLS abilities of openldap? Thanks Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

3 2

RE: Syncrepl and mmr
by Quanah Gibson-Mount 19 Feb '14

19 Feb '14

--On Wednesday, February 19, 2014 2:20 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > First had this (mm-server1): > 5304e1ff olcMirrorMode: value #0: <olcMirrorMode> database is not a shadow > slapadd: could not add entry dn=olcDatabase={1}bdb,cn=config (line=2260) For MMR Mode, MirrorMode must be set to TRUE. If it does not accept TRUE then there is something wrong with your configuration. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

how to get list of valid attributes
by Umar Draz 18 Feb '14

18 Feb '14

HI All I want a list of valid attributes for specific objectClass e.g. I have a user abc with the dn of this user is cn=Abc User,ou=accounts,dc=mydom,dc=com the abc user has these object classes posixAccount shadowAccount OrginizatinalPerson yubikeyUser now I want to get the valid schema attribute of yubikeyUser for only the above mentioned user. Is this possible? Umar

4 3

ldapsearch error - Unknown error (60)
by Auteria W. Winzer Jr. 18 Feb '14

18 Feb '14

To the members of the mailing list, Upon a test search I'm getting the following error: $ ldapsearch -LLL -v -z none -x -e "2.16.840.1.113730.3.4.9" -h bugsbunny.bar -p 9999 -b "ou=foo,o=bar" -D "uid=xxx,ou=foo,o=bar" -w "xxxxxxxx" "(&(objectClass=groupOfUniqueNames)(displayname=*))" displayname ldap_initialize( ldap://bugsbunny.bar:9999 ) filter: (&(objectClass=groupOfUniqueNames)(displayname=*)) requesting: displayname Unknown error (60) Additional information: VLV Control When looking up the error I noticed the following: LDAP_SORT_CONTROL_MISSING - 60 (x'3C) - Unused in standards. Sun LDAP Directory Server only. Server did not receive a required server-side sorting control. Can someone that has experience with this type of LDAP search criteria assist me to obtain a final resolution? Thanks to everyone, and regards, Auteria Winzer Jr.

4 11

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical