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.
--On Wednesday, May 02, 2018 1:12 PM +0000 Ole Nomann Thomsen ole.nomann@stil.dk wrote:
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 :-]
If you are using standard syncrepl for replication, this can happen when the system goes into REFERSH mode IIRC. It generally means a child entry was replicated before the parent was replicated.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Wednesday, May 02, 2018 1:12 PM +0000 Ole Nomann Thomsen ole.nomann@stil.dk wrote:
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 :-]
If you are using standard syncrepl for replication, this can happen when the system goes into REFERSH mode IIRC. It generally means a child entry was replicated before the parent was replicated.
Although usually, the glue entry should turn back into a regular entry when the parent entry eventually gets replicated.
openldap-technical@openldap.org