Hi William,
Thanks for the response. I'll check on that and let you know if that resolves the problem or not. Thanks again.
On 1/16/19, 3:02 PM, "William Brown" <wbrown@xxxxxxx> wrote:
> 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
_______________________________________________
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
