> On 17 Jan 2019, at 06:25, Jason Jenkins <jjenkins@xxxxxxxxxxxxxxxx> wrote: > > Hi, > > One of my consumers is showing the following error: > > Entry "uid=XXXX,ou=People,dc=XXX" has unknown object class "ldapPublicKey" > WARNING: passwordPolicy modify error 65 on entry uid=XXXX,ou=People,dc=XXX > > > This error is coming up for anyone that tries to authenticate against this consumer. It is slowing down authentication. Nothing has change on the directory server side that I can tell and my masters aren’t having these issues. Any ideas? Hey there, I can only see one reference to “ldapPublicKey” in our code base, from a patch I wrote a few years back: - # This may not always work at sites? - # Can we get this into core? - # 'ldapPublicKey’, This triggered my memory, and I think that ldapPublicKey is from the openssh ldapschema. It’s used by default with SSSD with the sss_ssh_authorized keys program to try and check if a public key is available from the directory for use: sadly we don’t endorse this schema as it has an issue (must not may, so can’t self service). We support the schema: nsSshPublicKey. Anyway, there are a few possible resolutions. If you ARE using ldap ssh keys, you may be missing schema from your master that is present on others. This may be due to a change on 99user.ldif or similar. It would be worth your time to compare the content of the instance schema directories between a functional and non-functional server. This should be in /etc/dirsrv/slapd-<instance>/schema/*.ldif . From there, if you find differences, correct the faulty server to have the schema from the “good” server. Alternately, I’d strongly consider doing a migration/change to our supported nsSshPublicKey attribute and rolling that out. If you are NOT using ssh keys in ldap from sssd, the issue is probably in your SSSD client. In /etc/sssd/sssd.conf look for: [sssd] services = nss, pam, ssh, sudo Remove ssh from the list of service, and this will disable the public key lookup. I hope this helps, > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
