openldap-technical

openldap-technical@openldap.org

9 participants
9873 discussions

OpenLDAP Replication configuration error!
by pradyumna dash 03 Nov '11

03 Nov '11

Hi, I am facing an issue with multi master replication in Redhat Enterprise linux 5.7 with Openldap 2.3.43-12.el5_6.7 When am trying to delete or create any user , in the log it says : "err=53 text=shadow context; no update referral." My Configuration file is attached, in the other node i have changed the ServerID and the refereal server IP. Please help me to fix this issue. Regards, Neo

1 0

problem changing {0}config
by Christopher Wood 03 Nov '11

03 Nov '11

Question: What is happening that I can turn a multimaster replica into a "shadow context"? (I'm more or less fine with the behaviour since I don't mind stopping the multimaster slapd's to do a password change, but I'm concerned that I may have missed some underlying problem in my setup.) I've found that issuing a particular set of changes to one or both cn=config multimaster replicas means that I cannot issue any more changes to cn=config until I restart slapd. The ldif I paste into my ldapmodify session is this (changed the hostname and credentials from the real ones): dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: {0}rid=1 provider=ldap://ldap-supplier-lab-01.company.com binddn="cn=config" bindmethod=simple credentials=newpw searchbase="cn=config" type=refreshAndPersist retry="5 5 30 +" timeout=5 olcSyncrepl: {1}rid=2 provider=ldap://ldap-supplier-lab-02.company.com binddn="cn=config" bindmethod=simple credentials=newpw searchbase="cn=config" type=refreshAndPersist retry="5 5 30 +" timeout=5 - replace: olcRootPW olcRootPW: newpw I get this output: modifying entry "olcDatabase={0}config,cn=config" Then I observe the following behaviour: I can ldapsearch with the new password and get the expected result (ldif output of the cn=config database). When I ldapmodify with the new password I get this output: modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral After I restart slapd I get the expected behaviours with both ldapsearch (get ldif output) and ldapmodify (can change cn=config). Further, I've diffed the ldif output of directories before and after this change, and I do not see any difference apart from the attributes that I've changed.

3 4

SyncRepl for subtree
by sim123 03 Nov '11

03 Nov '11

Hi All, I am trying to setup syncrepl, and consumer needs only one subtree from provider and I want to create another subtrees in consumer side, something like this mentioned in this post: http://www.openldap.org/lists/openldap-software/200610/msg00126.html and I am getting same error with openldap-2.4.26, just wanted to check if its possible now? I can't update provider so updateref is not a solution for me. I would greatly appreciate any help. Thanks

2 1

Password policy complexity
by Hugo Deprez 03 Nov '11

03 Nov '11

Dear community, I would like to specify the complexity of the password for users. For exemple a password must contain : one specific character such as : !£"$%^&*()-_+=:;'@~#?<> one capital letter etc... The password policy overlay only authorize to specify the number of character. Is that possible ? Regards, Hugo

2 4

Debugging database crashes
by Ian Collins 31 Oct '11

31 Oct '11

I have a freshly built system db-5.2.36 and openldap-2.4.23. I keep seeing these entries in slapd.log: @(#) $OpenLDAP: slapd 2.4.23 (Oct 31 2011 23:39:29) $ @ldaphost:/build/openldap-2.4.23/servers/slapd hdb_db_open: database "": unclean shutdown detected; attempting recovery. hdb_monitor_db_open: monitoring disabled; configure monitor database to enable slapd starting Any hints on tracing what is crashing and why? -- Ian.

1 0

Pb with sasl2 digest - md5 and openldap
by bea chataigne 30 Oct '11

30 Oct '11

On a redhat 6, openldap 2.4 and cyrus-sasl 2.1.23. I create a sasldb syncuser user, in my slapd.d configuration I add: OlcAuthzRegexp: {0} " uid=syncuser, cn=DIGEST-MD5, cn=auth " " cn=syncuser, dc=xxx, dc=fr " I give the right of reading has the utisilsateur ldap on sasldb. PB during a ldapsearch: # ldapsearch -Y DIGEST-MD5-U syncuser ldap_sasl_interactive_bind_s: Invalid credentials ( 49 ) additional information: SASL ( 13 ): use(wear out) not found: no secret in database Slapd in debug mode(fashion) sends back(dismisses) to me: slapd[2608]: do_bind: dn () SASL mech DIGEST-MD5 slapd[2608]:slapd[2608]: ==> sasl_bind: dn="" mech=<continuing> datalen=277 slapd[2608]: SASL [conn=1002] Debug: DIGEST-MD5 server step 2 slapd[2608]: SASL Canonicalize [conn=1002]: authcid="syncuser" slapd[2608]: slap_sasl_getdn: conn 1002 id=syncuser [len=8] slapd[2608]: slap_sasl_getdn: u:id converted to uid=syncuser,cn=DIGEST-MD5,cn=auth slapd[2608]: >>> dnNormalize: <uid=syncuser,cn=DIGEST-MD5,cn=auth> slapd[2608]: <<< dnNormalize: <uid=syncuser,cn=digest-md5,cn=auth> slapd[2608]: ==>slap_sasl2dn: converting SASL name uid=syncuser,cn=digest-md5,cn=auth to a DN slapd[2608]: [rw] authid: "uid=syncuser,cn=digest-md5,cn=auth" -> "cn=syncuser,dc=xxx,dc=fr" slapd[2608]: slap_parseURI: parsing cn=syncuser,dc=xxx,dc=fr slapd[2608]: >>> dnNormalize: <cn=syncuser,dc=xxx,dc=fr> slapd[2608]: <<< dnNormalize: <cn=syncuser,dc=xxx,dc=fr> slapd[2608]: <==slap_sasl2dn: Converted SASL name to cn=syncuser,dc=xxx,dc=fr slapd[2608]: slap_sasl_getdn: dn:id converted to cn=syncuser,dc=xxx,dc=fr slapd[2608]: SASL Canonicalize [conn=1002]: slapAuthcDN="cn=syncuser,dc=xxx,dc=fr" slapd[2608]: => hdb_search slapd[2608]: daemon: activity on 1 descriptor slapd[2608]: daemon: activity on: slapd[2608]: slapd[2608]: daemon: epoll: listen=7 active_threads=1 tvp=zero slapd[2608]: daemon: epoll: listen=8 active_threads=1 tvp=zero slapd[2608]: daemon: epoll: listen=9 active_threads=1 tvp=zero slapd[2608]: daemon: epoll: listen=10 active_threads=1 tvp=zero slapd[2608]: bdb_dn2entry("cn=syncuser,dc=xxx,dc=fr") slapd[2608]: => hdb_dn2id("cn=syncuser,dc=xxx,dc=fr") slapd[2608]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) slapd[2608]: => access_allowed: disclose access to "dc=xxx,dc=fr" "entry" requested slapd[2608]: => dnpat: [5] uid=([^,].*),ou=People,dc=xxx,dc=fr nsub: 1 slapd[2608]: => dnpat: [6] uid=([^,].*),ou=People,dc=xxx,dc=fr nsub: 1 slapd[2608]: => dn: [7] ou=people,dc=xxx,dc=fr slapd[2608]: => dn: [8] ou=admin,dc=xxx,dc=fr slapd[2608]: => dn: [9] ou=services,dc=xxx,dc=fr slapd[2608]: => dnpat: [10] ou=groups,ou=(.*),ou=web,dc=xxx,dc=fr nsub: 1 slapd[2608]: => dnpat: [11] ou=(.*),ou=web,dc=xxx,dc=fr nsub: 1 slapd[2608]: => acl_get: [12] attr entry slapd[2608]: => acl_mask: access to entry "dc=xxx,dc=fr", attr "entry" requested slapd[2608]: => acl_mask: to all values by "", (=0) slapd[2608]: <= check a_dn_pat: * slapd[2608]: <= acl_mask: [2] applying read(=rscxd) (stop) slapd[2608]: <= acl_mask: [2] mask: read(=rscxd) slapd[2608]: => slap_access_allowed: disclose access granted by read(=rscxd) slapd[2608]: => access_allowed: disclose access granted by read(=rscxd) slapd[2608]: send_ldap_result: conn=1002 op=1 p=3 slapd[2608]: send_ldap_result: err=10 matched="dc=xxx,dc=fr" text="" slapd[2608]: SASL Canonicalize [conn=1002]: authzid="syncuser" slapd[2608]: SASL [conn=1002] Failure: no secret in database slapd[2608]: send_ldap_result: conn=1002 op=1 p=3 slapd[2608]: send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no secret in database" slapd[2608]: send_ldap_response: msgid=2 tag=97 err=49 slapd[2608]: conn=1002 op=1 RESULT tag=97 err=49 text=SASL(-13): user not found: no secret in database slapd[2608]: <== slap_sasl_bind: rc=49 slapd[2608]: daemon: activity on 1 descriptor slapd[2608]: daemon: activity on: slapd[2608]: 31r Thank you for your suggestions. B Chataigne

2 2

directory performance on modifytimestamp and createtimestamp
by Flack, Simon 28 Oct '11

28 Oct '11

All, Has anyone tried creating an index in openldap to speed-up inequality searches ( eg of the form modifyTimestamp>=20111025162408Z ) on the modifytimestamp or createtimestamp attributes ? If so, what type of index did you create , did openldap perform reads faster than with no index and did the presence of the index slow down writes to openldap appreciably ? Many Thanks, Simon Flack. This e-mail has been scanned for viruses by the Cable&Wireless Worldwide e-mail security system. For more information on a proactive managed e-mail secure service, visit http://www.cw.com/managed-exchange The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable & Wireless Worldwide plc Registered in England and Wales. Company Number 07029206 Registered office: Liberty House, 76 Hammersmith Road, London W14 8UD, England

2 1

[Autofs for Linux and OSX] back-relay ? aliases ?
by Frava 28 Oct '11

28 Oct '11

Hello, I'm configuring Autofs maps via OpenLDAP for some OS X (10.5/6/7) and Linux CentOS (5/6) boxes, and I'm running into a little problem. OS X needs to have an "automountMapName=auto_master" and "automountMapName=auto_home" located in "cn=automountMap,dc=subnet,dc=example,dc=com" Linux needs to have an "automountMapName=auto.master" and "automountMapName=auto.home" located wherever I want in "dc=subnet,dc=example,dc=com" The entries contained in "automountMapName=auto_home" and "automountMapName=auto.home" will be exactly the same ones; SO what is the best way to implement it without duplicate them ? Using aliases or rwm+relay ? Cheers, Rafael.

3 4

Re: [Autofs for Linux and OSX] back-relay ? aliases ?
by Frava 28 Oct '11

28 Oct '11

Well, if your automount-informations are not the same on both OSes then you clearly have to duplicate/arrange them ;). People here use several programs which save the working directory for each project. That (and the fact that users can log onto whatever worstation they want to) makes me mount all the nfs directories in the same place on each computer. Cheers, Rafael. 2011/10/28 myron <kowalskM(a)cs.moravian.edu> > I ran into the same config issue. I ended up duplicating the maps because I > had the macs mount on /home and linux on /users; > otherwise, I would have just renamed the auto maps on either OS to be the > same. > > --myron > ==============================**=== > Myron Kowalski > MoCoSIN Network/Systems Administrator > Moravian College > myron(a)cs.moravian.edu > > > > > On Oct 28, 2011, at 10:13 AM, Frava wrote: > > Hello, >> >> I'm configuring Autofs maps via OpenLDAP for some OS X (10.5/6/7) and >> Linux CentOS (5/6) boxes, and I'm running into a little problem. >> >> OS X needs to have an "automountMapName=auto_master" and >> "automountMapName=auto_home" located in "cn=automountMap,dc=subnet,dc=** >> example,dc=com" >> Linux needs to have an "automountMapName=auto.master" and >> "automountMapName=auto.home" located wherever I want in >> "dc=subnet,dc=example,dc=com" >> >> The entries contained in "automountMapName=auto_home" and >> "automountMapName=auto.home" will be exactly the same ones; SO >> what is the best way to implement it without duplicate them ? Using >> aliases or rwm+relay ? >> >> Cheers, >> Rafael. >> > >

1 0

Re: LDAP + Freeradius + Samba
by Andreas Rudat 28 Oct '11

28 Oct '11

Am 28.10.2011 09:44, schrieb Stewart Walters: > On any given Linux system (assuming that's what your using), NSS and PAM do all the authentication. > > In terms of client tools, they link to (and therefore leverage) NSS and PAM, which OpemLDAP plugs in to. > > It's often irrelevant if you use ntlm_pam, mschap, samba+winbind, pam_ldap, freeradius, Authz or any other client tool. They all link back to NSS and PAM, which when configured correctly plugs in to OpenLDAP. > > Stewart Ok thanks but if I don't missunderstand the documentation, then it only works with clear passwords? But is it save enough then? Because peap isn't supported then, too. Andreas > > On 28/10/2011, at 2:49 PM, Andreas Rudat <rudat(a)endstelle.de> wrote: > >> Am 28.10.2011 04:28, schrieb Stewart Walters: >>> Freeradius already supports posixAccount attributes for LDAP account authentication - check the Freeradius website for a howto. >>> >>> Freeradius and OpenLDAP also supports the storing of 802.1x attributes using the RADIUS schema. >>> >>> There are numerous howto's available on the web for how to implement either. >>> >>> >>> >>> >>> On 28/10/2011, at 3:28 AM, Andreas Rudat <rudat(a)endstelle.de> wrote: >>> >>>> Hello, >>>> >>>> I got openldap running as user db for samba, now I want to use it also >>>> as database for radius, I think it should be possible to use it without >>>> big modifications or? >>>> >>>> Thanks >>>> >> ok thanks, I will look. Another question is, does I need any other >> client tools for windows/linux? At the moment I'm using ntlm_auth + mschap >> >> Andreas >> >> -- >> >> -----BEGIN PGP PUBLIC KEY BLOCK----- >> Version: GnuPG v2.0.17 (MingW32) >> >> mQGNBE6jHfABDACyzFkn6k+OtbRANjKZ6NEQOxnnsBSBSs6sT9EBF0U3MnnYW3/p >> YTW+7aUa/1FZTOWt9wb9H7t0SOqpgqUBmRo/sPteepXblnDaGEh8tzIWfaC9MKc1 >> QobU5zK9KcDKrs3SyGXEPOOQM8QdtE8KfSJFdUxfanFJUbfTbxq5Gqz1eaU4cWxp >> gR6GeVYnd11J8AdDDwkjPjx4ZJ5guZ+D646Qi3CT7KT6y8sXVPwpNA3CvGweYX0r >> STKyBf+nlQtOtByrgZW7BiSAxilYUL4mGE4KmuYAadJ+O6X7NOtz3OQaWgSGjqxH >> YxDu6orTzL4/csjoVXS9dgeGkhLJgAg72a2yxA4tx/8IXrGp3JVGYGEY2kYcq3k9 >> jq5hJezoy6s1N//mgm5KaB84zrU5cUcu8kXDppmnp7eXUPnBqj2g2O82buBNa48S >> wAtnbY4K5fbcnog8g6ouYXpAJo9yHcj+wraQ8+TNFx5nbkg3fZKuf3UeyL3dPKXf >> wsKehnZ3Ipqkb08AEQEAAbQiQW5kcmVhcyBSdWRhdCA8cnVkYXRAZW5kc3RlbGxl >> LmRlPokBuAQTAQIAIgUCTqMd8AIbDwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AA >> CgkQBw5gh+kRIv+yGQv5AQCRZt8wR2McgsTurZEZXz5UpxEPZB/dA/iXtPzZXJih >> XLRZFqcdT+c8DCLbhXjO5aLndOCIDwWmsnqX2fuGAjlM4GJAAUEARSNtWY7V+rUt >> PhdOz/flCZo/+p7wBi0XOJcWhysS7DV/ssSYdnuJvONUBXCQ/MpJsVXuKdgPa9IR >> hvi37Ang1Cxb7htKHIuA4wCuqz1/4VGNez/65qwjuYakbB4/rXkKWb17XqCZrtoo >> YiQSxPU7fP5lM4ybQXxP1qrptmaF9EqGTnj/xAU3tCE+PhB3baoVw6VG9nr9xYwh >> bqCGtTbtrkmYlgioC2fFHDgg3U1GVBIbi0AoddXSs5OekgSvt827OcyWVSyjobyn >> tH4/jwb8X8iOM/x8RZhzwKhpHA0k7ltTm7qXApARcL1tV6y4GIKwuy1RLZqkpNh1 >> teqYaxAKlxC77s6gftxqr7G6NCssgCCy2Y50LSvcQbZDPZeBdrPoGI/xAWNy4Otv >> 33k4P9hxJKHNqLYJN+Gn >> =UaS9 >> -----END PGP PUBLIC KEY BLOCK----- >> -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (MingW32) mQGNBE6jHfABDACyzFkn6k+OtbRANjKZ6NEQOxnnsBSBSs6sT9EBF0U3MnnYW3/p YTW+7aUa/1FZTOWt9wb9H7t0SOqpgqUBmRo/sPteepXblnDaGEh8tzIWfaC9MKc1 QobU5zK9KcDKrs3SyGXEPOOQM8QdtE8KfSJFdUxfanFJUbfTbxq5Gqz1eaU4cWxp gR6GeVYnd11J8AdDDwkjPjx4ZJ5guZ+D646Qi3CT7KT6y8sXVPwpNA3CvGweYX0r STKyBf+nlQtOtByrgZW7BiSAxilYUL4mGE4KmuYAadJ+O6X7NOtz3OQaWgSGjqxH YxDu6orTzL4/csjoVXS9dgeGkhLJgAg72a2yxA4tx/8IXrGp3JVGYGEY2kYcq3k9 jq5hJezoy6s1N//mgm5KaB84zrU5cUcu8kXDppmnp7eXUPnBqj2g2O82buBNa48S wAtnbY4K5fbcnog8g6ouYXpAJo9yHcj+wraQ8+TNFx5nbkg3fZKuf3UeyL3dPKXf wsKehnZ3Ipqkb08AEQEAAbQiQW5kcmVhcyBSdWRhdCA8cnVkYXRAZW5kc3RlbGxl LmRlPokBuAQTAQIAIgUCTqMd8AIbDwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AA CgkQBw5gh+kRIv+yGQv5AQCRZt8wR2McgsTurZEZXz5UpxEPZB/dA/iXtPzZXJih XLRZFqcdT+c8DCLbhXjO5aLndOCIDwWmsnqX2fuGAjlM4GJAAUEARSNtWY7V+rUt PhdOz/flCZo/+p7wBi0XOJcWhysS7DV/ssSYdnuJvONUBXCQ/MpJsVXuKdgPa9IR hvi37Ang1Cxb7htKHIuA4wCuqz1/4VGNez/65qwjuYakbB4/rXkKWb17XqCZrtoo YiQSxPU7fP5lM4ybQXxP1qrptmaF9EqGTnj/xAU3tCE+PhB3baoVw6VG9nr9xYwh bqCGtTbtrkmYlgioC2fFHDgg3U1GVBIbi0AoddXSs5OekgSvt827OcyWVSyjobyn tH4/jwb8X8iOM/x8RZhzwKhpHA0k7ltTm7qXApARcL1tV6y4GIKwuy1RLZqkpNh1 teqYaxAKlxC77s6gftxqr7G6NCssgCCy2Y50LSvcQbZDPZeBdrPoGI/xAWNy4Otv 33k4P9hxJKHNqLYJN+Gn =UaS9 -----END PGP PUBLIC KEY BLOCK-----

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical