Oh. Answering my own question: The "missing" entry had turned into a glue entry, don't know how. I can modify it with "ldapmodify ... -M ..." (or maybe -MM), to turn it into a regular entry and make dotnet default auth work.
Thanks for your time :-] - Ole. > Hi list, I am running @(#) $OpenLDAP: slapd 2.4.45 (Jan 23 2018 08:50:30) $ > for > authentication. > > I can authenticate most of my clients, but some of them fail. It seems to be > the .net ones, not using fastbind: > One client tries to authenticate from .net, but can't bind. This is in the > log: > > conn=12475338 fd=15 ACCEPT from IP=192.168.252.131:36473 > (IP=0.0.0.0:3890) > conn=12475338 op=0 BIND dn="uid=wscda,ou=Authentication,o=UNI- > C,c=DK" method=128 > conn=12475338 op=0 BIND dn="uid=wscda,ou=Authentication,o=UNI- > C,c=DK" mech=SIMPLE ssf=0 > conn=12475338 op=0 RESULT tag=97 err=0 text= > conn=12475338 op=1 srch base="ou=authentication,o=uni-c,c=dk" scope=0 > deref=0 filter="(objectclass=*)" > conn=12475338 op=1 srch attr=objectclass > conn=12475338 op=1 search result tag=101 err=0 nentries=0 text= > > Aha, "ou=authentication,o=uni-c,c=dk" (that default .net auth seems to > require) must be missing. Verify that: > > ldapsearch -x -H ldaps://host:3891/ -D "..." -w "..." -s base -b > ou=Authentication,o=UNI-C,c=DK objectClass=* + \* > > Gives me: > > # extended LDIF > # > # LDAPv3 > # base <ou=Authentication,o=UNI-C,c=DK> with scope baseObject > # filter: entryUUID=* > # requesting: + * > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > With this log-entry: > > conn=10181 fd=14 ACCEPT from IP=10.54.43.87:54312 (IP=0.0.0.0:3891) > conn=10181 fd=14 TLS established tls_ssf=256 ssf=256 > conn=10181 op=0 BIND dn="cn=AuthAdmin,ou=Authentication,o=UNI- > C,c=DK" method=128 > conn=10181 op=0 BIND dn="cn=AuthAdmin,ou=Authentication,o=UNI- > C,c=DK" mech=SIMPLE ssf=0 > conn=10181 op=0 RESULT tag=97 err=0 text= > conn=10181 op=1 SRCH base="ou=Authentication,o=UNI-C,c=DK" scope=0 > deref=0 filter="( objectClass=*)" > conn=10181 op=1 SRCH attr=+ * > conn=10181 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= > conn=10181 op=2 UNBIND > > That is "nentries=0", yup it is missing. > > I decide to add the missing structural object: > > ldapadd -h localhost -p 3890 -f missing.ldif -D "..." -w "..." > > with missing.ldif: > > dn: ou=Authentication,o=UNI-C,c=DK > ou: Authentication > objectClass: organizationalUnit > > Result: > > adding new entry "ou=Authentication,o=UNI-C,c=DK" > ldap_add: Already exists (68) > > And this log-entry: > > conn=10182 op=1 ADD dn="ou=Authentication,o=UNI-C,c=DK" > slap_queue_csn: queueing 0x7f63c811e390 > 20180501061454.852525Z#000000#000#000000 > conn=10182 op=1 RESULT tag=105 err=68 text= > > There or not? I try to delete it: > > ldapdelete -h localhost -p 3890 -f missing-delete.ldif -D "..." -w "..." > > missing-delete.ldif: > > ou=Authentication,o=UNI-C,c=DK > > Result: > > ldap_delete: No such object (32) > matched DN: ou=Authentication,o=UNI-C,c=DK > > Log: > > conn=10184 op=1 DEL dn="ou=Authentication,o=UNI-C,c=DK" > conn=10184 op=1 RESULT tag=107 err=32 text= > > I can't add it, beacause it's already there, and I can't delete it, because > it isn't > there... > I can't figure out what the problem is; maybe som subtle difference between > what is in the base and what I am searching for? > I've a feeling that there is a face-palm answer, if so please bear with me.
