openldap-technical October 2016

openldap-technical@openldap.org

44 participants
57 discussions

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 27 Oct '16

27 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

Re: Account computer
by Kwame Bahena 27 Oct '16

27 Oct '16

LOL. Don't get upset. You didn't mention at first that you are using samba with OpenLDAP. Take a look at this link http://lmgtfy.com/?q=disable+inactive+accounts+Samba+with+OpenLDAP On Thu, Oct 27, 2016 at 12:33 PM, Itamar S. <immaggoo(a)gmail.com> wrote: > > 2016-10-27 15:32 GMT-02:00 Itamar S. <immaggoo(a)gmail.com>: > >> Fk you. >> >> If I had a CD would have done. I'm using Samba with OpenLDAP. >> > > Fk you. > > If I had a AD would have done. I'm using Samba with OpenLDAP. >

1 0

Account computer
by Itamar S. 27 Oct '16

27 Oct '16

Hello, How can I disable accounts computer that have been inactive for 180 days?

3 2

Proxy cache not work with <attribute not in schema>
by JWD 27 Oct '16

27 Oct '16

slapd 2.4.40 Windows AD as proxy backend. I found any query match <pcacheTemplate>+<pcacheAttrset>+<attribute not in schema> will answer <pcacheAttrset> value only, <attribute not in schema> will be ignored. This is not what I expected, I need <attribute not in schema> too. But query anything else that not in cache, <attribute not in schema> will be cached. Log message like this: 580ec506 PROXIED attributeDescription "PRIMARYGROUPID" inserted. And after that, query match <pcacheTemplate>+<pcacheAttrset>+<attribute not in schema> will answer <attribute not in schema> too. This is what I expected. Do I have to add schema for <attribute not in schema>? Is there any other way to make <attribute not in schema> CACHEABLE? -------------- JWD

2 2

Re: delta-synrepl consumer randomly delete objects
by Quanah Gibson-Mount 26 Oct '16

26 Oct '16

--On Thursday, October 20, 2016 10:19 AM +0200 Raffael Sahli <public(a)raffaelsahli.com> wrote: > Hi > > What can lead a consumer to "randomly" delete ~50% of all objects in his > database? I have this problem now for ~1-2months and on 3 different > master/slave groups. > > The consumer starts to delete objects (but those are all present on the > master): > > Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 19 17:16:22 ldap-slave002.xxx This is not delta-syncrepl, this is syncrepl. What triggered your system to fall back to syncrepl? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2016