openldap-technical

openldap-technical@openldap.org

13 participants
9794 discussions

Re: Public LDAP server, what do I need to know?
by Quanah Gibson-Mount 01 Nov '16

01 Nov '16

--On Sunday, October 16, 2016 3:29 PM -0400 John Lewis <oflameo2(a)gmail.com> wrote: > I want to host a LDAP server that contains a directory that contains the > offices of local Representatives and Public Servants, the issues they > are responsible for, and their names. I would like anyone who wants to > to browse it or put up front ends. > > Is there anything in particular that I should keep in mind? Keep your tree as flat as possible, as deep as necessary, is the guiding wisdom. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Antw: openldap 2.4.40 ppolicy module and shadowInactive equivalent
by Real, Elizabeth (392K) 31 Oct '16

31 Oct '16

Ulrich, Yes, I already have nis.ldif loaded. What else do you suggest? Thank you, Liz From: Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> Date: Monday, October 24, 2016 at 11:17 PM To: "Real, Elizabeth (392K)" <Elizabeth.Real(a)jpl.nasa.gov>, "openldap-technical(a)openldap.org" <openldap-technical(a)openldap.org> Subject: Antw: openldap 2.4.40 ppolicy module and shadowInactive equivalent "Real, Elizabeth (392K)" <Elizabeth.Real(a)jpl.nasa.gov<mailto:Elizabeth.Real@jpl.nasa.gov>> schrieb am 24.10.2016 um 20:43 in Nachricht <0C90A104-2EF4-4AA6-8748-05B07154A54D(a)jpl.nasa.gov<mailto:0C90A104-2EF4-4AA6-8748-05B07154A54D@jpl.nasa.gov>>: Hello, I setup a password policy overlay on my openldap 2.4.40 servers running RHEL7. I need to enforce the following: disable accounts that have been inactive for 180 days. In the past we were able to do this by simply adding the shadowInactive attribute to each account: shadowInactive 180. But with the new openldap, it appears there is no equivalent attribute?? Why didn't you "grep shadowInactive /etc/openldap/schema/*"? It appears in nis.ldif, nis.schema, and rfc2307bis.schema. (I only have SLES11 SP4 here, but there shouldn't be a big difference) Ulrich http://www.openldap.org/doc/admin24/ http://www.zytrax.com/books/ldap/ch6/ppolicy.html Thank you, Liz

1 1

Re: Syncrepl only partially working
by Quanah Gibson-Mount 31 Oct '16

31 Oct '16

--On Sunday, October 30, 2016 11:16 AM +0100 Dieter Klünter <dieter(a)dkluenter.de> wrote: > It is a bit more complicated than that. > syncrepl is a client operation, which requires ldap client > configuration, specified in ldap.conf(5). You can set these specifically for the syncrepl client as a part of your syncrepl configuration stanza, rather than ldap.conf. See slapd.conf(5) or slapd-config(5), the section on syncrepl/olcSyncRepl, the sizelimit and timelimit parameters. But, regardless, the server limits on the master trump any client settings that are higher than the defaults, so as Dieter noted, they must be increased on the master to "unlimited" for at least the replicator DN. This is of course covered in the admin guide. For example, in section 18.3.2, we find: # Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=symas,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited as one example. etc. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Defining timeouts in slapd-ldap Backend
by Daniel Betz 31 Oct '16

31 Oct '16

Hi List, i have an problem with slapd-ldap backend and the timeouts. There are many timeouts to configure, but i think they dont work in the tls handshake phase. 5816f773 send_ldap_result: conn=-1 op=0 p=0 5816f773 backend_startup_one: starting "sid=3092,sec=webhosting,o=xxxxxx,c=de" 5816f773 ldap_back_db_open: URI=ldaps://sid3092.int.webslave.xxxxxxx ldap_create ldap_url_parse_ext(ldaps://sid3092.int.webslave.xxxxxxxx) 5816f773 =>ldap_back_getconn: conn=-1 op=0: lc=0x37c2880 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 sid3092.int.webslave.xxxxxxxxx:636 ldap_new_socket: 256 ldap_prepare_socket: 256 ldap_connect_to_host: Trying 10.xx.xx.xx:636 ldap_pvt_connect: fd: 256 tm: 5 async: 0 ldap_ndelay_on: 256 attempting to connect: connect errno: 115 ldap_int_poll: fd: 256 tm: 5 ldap_is_sock_ready: 256 ldap_ndelay_off: 256 ldap_pvt_connect: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A And then the slapd hangs and hangs. I know that the consumer ldap is running, but the server itself hangs with an error. In this slapd there are 250 more servers to serve via slapd-ldap, so this will cause an big problem when only one server hangs and the slapd stucks forever. Are there any other timeouts to configure in slapd-ldap backend ? Here´s the slapd.conf: database ldap hidden on suffix "sid=3092,sec=webhosting,o=xxxxxxxx,c=de" rootdn "cn=xxxxxxxx,sid=3092,sec=webhosting,o=xxxxxxxxx,c=de" uri ldaps://sid3092.int.webslave.xxxxxxxxx network-timeout 5 timeout bind=5 lastmod on restrict all acl-bind bindmethod=simple binddn="cn=xxxxxx,sid=3092,sec=webhosting,o=xxxxxx,c=de" credentials="PASSWORD" syncrepl rid=3092 provider=ldapi://%2Fvar%2Frun%2Fldapi binddn="cn=Manager,o=xxxxxxxxxxx,c=de" bindmethod=simple credentials=PASSWORD searchbase="sid=3092,sec=webhosting,o=xxxxxxxxxx,c=de" type=refreshAndPersist retry="10 6 30 +" overlay syncprov Regards, Daniel Freundliche Grüße, Daniel Betz System Design Engineer / Senior Systemadministration ___________________________________ domainfactory GmbH Oskar-Messter-Str. 33 85737 Ismaning Germany Telefon: +49 (0)89 / 55266-364 Telefax: +49 (0)89 / 55266-222 E-Mail: dbetz(a)df.eu<mailto:dbetz@df.eu> Internet: www.df.eu<http://www.df.eu/> Registergericht: Amtsgericht München HRB-Nummer 150294, Geschäftsführer: Tobias Mohr, Stephan Wolfram

1 0

Syncrepl only partially working
by Joshua Schaeffer 30 Oct '16

30 Oct '16

Greetings all, I'm trying to figure out why Syncrepl is only syncing part of my provider's database when I use GSSAPI to connect. Both my provider and consumer are on 2.4.40. Here are all the steps I'm taking: My provider is working fine, I've been using it for months now without any issues. I added this to the provider: dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig entryUUID: b32ac160-29e6-1036-8d0a-07ef98fd592e creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20161019012544Z olcSpSessionlog: 100 entryCSN: 20161024233803.817199Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20161024233803Z I also indexed entryCSN and entryUUID on the provider. I have olcAuthzRegexp setup on the provider as well. olcAuthzRegexp: {0}"uid=admin,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=admin,dc=harmonywave,dc=com" olcAuthzRegexp: {1}"uid=ldap/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth" "dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" olcAuthzRegexp: {2}"uid=syncprov,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=syncprov,dc=harmonywave,dc=com" #not using this. olcAuthzRegexp: {3}"uid=.*\/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=admin,dc=harmonywave,dc=com" olcAuthzRegexp: {4}"uid=host\/([^.]*).harmonywave.com,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=$1+ipHostNumber=.*,ou=Hosts,dc=harmonywave,dc=com" olcAuthzRegexp: {5}"uid=([^/]*),cn=harmonywave.com,cn=GSSAPI,cn=auth" "uid=$1,ou=End Users,ou=People,dc=harmonywave,dc=com" On the consumer I have slapd installed. The first thing I did was change the olcSuffix on my database. I'm not sure if this is required or not. dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=harmonywave,dc=com - replace: olcRootDN olcRootDN: cn=admin,dc=harmonywave,dc=com Then I'm adding my ldap keytab for the consumer. kadmin: ktadd -k /etc/ldap/ldap.keytab ldap/consumer.harmonywave.com consumer: ~# chown openldap:openldap /etc/ldap/ldap.keytab consumer: ~# chmod 0640 /etc/ldap/ldap.keytab I edited my /etc/default/slapd file and pointed the KRB5_KTNAME environment variable to the new keytab then restarted slapd. Next I installed kstart and created a ticket cache. consumer: ~# k5start -U -f /etc/ldap/ldap.keytab -K 10 -l 24h -k /tmp/krb5cc_108 -o openldap -b I can see the ldap service's keytab with klist. consumer: ~# klist /tmp/krb5cc_108 Ticket cache: FILE:/tmp/krb5cc_108 Default principal: ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM Valid starting Expires Service principal 10/28/2016 21:18:14 10/29/2016 07:18:14 krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM renew until 10/29/2016 21:18:14 Then I add my olcSaslRealm dn: cn=config changetype: modify add: olcSaslRealm olcSaslRealm: HARMONYWAVE.COM Here is what my database looks like right before I add olcSyncrepl: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonym ous auth by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by * read olcLastMod: TRUE olcRootPW:: ... olcDbCheckpoint: 512 30 olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: 9a091324-2e84-1036-8b7a-73db8891632a creatorsName: cn=admin,cn=config createTimestamp: 20161024222607Z olcSuffix: dc=harmonywave,dc=com olcRootDN: cn=admin,dc=harmonywave,dc=com olcDbIndex: cn,uid eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: member,memberUid eq olcDbIndex: objectClass eq olcDbIndex: uidNumber,gidNumber eq entryCSN: 20161029033105.691204Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20161029033105Z then I add olcSyncrepl to the consumer. dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: {0}rid=000 provider=ldap://provider.harmonywave.com type=RefreshAndPersist retry="30 10 1800 +" searchbase="dc=harmonywave,dc=com" bindmethod=sasl saslmech=GSSAPI starttls=critical tls_cacert=/etc/ssl/certs/ca.harmonywave.com.pem tls_reqcert=demand After that I slapcat on the consumer and I only see about 1/3 of my data from the provider. When I watch the log on the provider this is what I get: Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 ACCEPT from IP=10.1.30.19:55992 (IP=0.0.0.0:389) Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 STARTTLS Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 RESULT oid= err=0 text= Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 TLS established tls_ssf=128 ssf=128 Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM))" Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences krbAllowedToDelegateTo Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/baneling.harmonywave.com(a)HARMONYWAVE.COM))" Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences krbAllowedToDelegateTo Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM))" Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences krbAllowedToDelegateTo Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=1 BIND dn="" method=163 Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=2 BIND dn="" method=163 Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND dn="" method=163 Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND authcid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM" authzid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM" Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND dn="uid=ldap/koprulu.harmonywave.com,cn=harmonywave.com,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=128 Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 RESULT tag=97 err=0 text= Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(objectClass=*)" Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH attr=* + Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=5 UNBIND Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 closed The only thing I really notice from this is near the end of the file. It when it searches the base with attributes "*+", but then immediately unbinds. I've seen people stating that authzid is required, but when I don't provide it I still get a partial sync, so I'm not sure about this. I've restored my consumer to a clean install of slapd and repeated the above steps with minor variations several times but the consumer always syncs the exact same amount of data and then seems to stop. Any help to point me in the right direction would be appreciated. Thanks, Joshua Schaeffer **

3 5

Re: Provider-Consumer replication 2.4 OLC (second attempt)
by Ted Hyde 28 Oct '16

28 Oct '16

1 0

some memberUid in my database are hashed
by Giovanni Biscuolo 28 Oct '16

28 Oct '16

Hi, I've an openldap database I use for auth purposes in which some memberUid is hashed while other not, e.g.: (results given by sudo ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b ou=Groups,dc=unit,dc=company,dc=net) .......................... dn: cn=GROUP,ou=Groups,dc=unit,dc=company,dc=net objectClass: top objectClass: posixGroup cn: GROUP gidNumber: 1026 memberUid: firstuser memberUid:: IGFyaWFubmE= [...] ........................... I cannot find any documentation about this kind of "memberUid hashed storage", the only differece is the double colon after memberUid please can you point me to the documentation or tell me how to "decode" the memberUid information also, on a client machine configured to use libnss-ldapd, if I list the groups with "sudo getent group" I can see the "clear text" members (e.g. firstuser in the example above) but not the "hashed" one; the same using the "members" command ciao Giovanni -- Giovanni Biscuolo Xelera - IT infrastructures http://xelera.eu/contact-us/

4 5

Changing server FQDN and certificate
by COMBES Julien - SG/SPSSI/CPII/DOSE/ET/PNE ANNUAIRE ET MESSAGERIE 28 Oct '16

28 Oct '16

Hello, Due to a decision of our IT Departement, I have to change the domain name of ours openldap servers and by extention all of their certificates. We have two ldap providers in mirror mode and fourteen ldap consumers. Those servers have ACL based (in part) on IP address to force TLS/SSL for some usages and they're accessed by a lots of ldap clients. I'm looking for a way to make a transition without duplicating all ldap servers during the time we change the fqdn and CA certificate on each client. This transition is quite easy with Apache and virtual host. AFAIK, openldap doesn't provide a Virtual Host system so I have to find an other way. I have tried a solution with stunnel which listens on an other IP address with a new certificate. But, as the connection from the stunnel to the ldap server comes from localhost and not from the original client, this is not working correctly with the ldaps's ACLs. Is someone have do this before or someone has an idea to do it ? Regards, Julien COMBES

2 1

Re: some memberUid in my database are hashed
by Giovanni Biscuolo 27 Oct '16

27 Oct '16

Hi Ulrich, * Ulrich Windl [2016-10-27 09:09:44 +0200]: [...] > > to be a little more clear: "getent group" does not show the base64 encoded > > users (aka listed as "memberUid:: ..." in LDIF) > > Which command did you use? "getent group" as I said :-) > Here (SLES11 SP4) a "getent passwd | grep 'the > entry you are looking for'" gives a corresponding result. me too, but I have issues "just" with memberUid attributes in my groups, not with usernames in general [...] > BTW: Decoding your "IGFyaWFubmE=" gives " arianna". A leading space in the > user name is _very_ experimental! OK let's assume it's _very_ experimental, anyway I just notice that: > > on the other side, "groups <user>" correctly lists all the groups the user > > is member of, despite the base64 encoding of its memberUid attribute so I don't really know why "groups" correctly lists LDAP groups in which user is listed as memberUid (base64 encoded with leading spaces), while "getent passwd" stops processing usernames at first base64 encountered name all I know is that standard unix file permissions and nfsv4 ACLs are working fine with this uncommon memberUid base64 encoded attributes for sure I'd avoid using base64 encoded memberUid attributes, but it happened somehow (still investigating) and it seems that having leading (or trailing?) spaces in that attribute (causing it to be base64 encoded) does not cause any problem to libnss-ldapd (pretty stadard configured) ...so, being very lazy, I'm investigating the possibility to leave the attributes alone and write a simple ldapsearch wrap script for my users to list all available groups and their members best regards Giovanni -- Giovanni Biscuolo Xelera - IT infrastructures http://xelera.eu/contact-us/ **per favore** Quota Bene: http://wiki.news.nic.it/QuotarBene **please** use Inline Reply: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

2 1

Re: Provider-Consumer replication 2.4 OLC (second attempt)
by Quanah Gibson-Mount 27 Oct '16

27 Oct '16

--On Tuesday, October 25, 2016 11:34 AM -0400 Ted Hyde <laserted(a)gmail.com> wrote: > Greets - (first post, second time. Don't know if it's being moderated or > dropped, will keep trying). It ended up in my spam folder for some reason. > After installation, I have two functioning standalone servers. During my > research, I found two conflicting pieces of information. I prefer to > perform "refreshOnly" instead of "refreshAndPersist", so some sources say > ONLY the consumers need configuration, a couple said both sides need > configuration AND a number of additional indices. This is likely where my > problems arise. I strongly advise only using refreshAndPersist. I'm not sure why you are referring to random how-not-to-do things on the interweb. You should use the OpenLDAP admin guide: <http://www.openldap.org/doc/admin24/replication.html> > Any thoughts? Read the admin guide, as noted above. The examples are still slapd.conf, but you can trivially translate those to what are necessary for cn=config. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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