On Fri, Mar 22, 2019 at 06:05:53AM -0000, Peter de Groot wrote:
please help.
On ubuntu against AD. Logging in with an AD account works fine.. EXCEPT for just ONE
account. The other AD accounts work fine
It will let me login once.. and when I try to login again, it comes up with access
denied.
BUT... if I do a sssctl cache-remove, it works again .. the first time.
id, and related diagnostics on this account come up fine..
Used realmd to add the machine to AD. sssd.conf below.
Level 10 logs for at first working and not working can be downloaded from
https://intranet.egc.wa.edu.au/downloads/sssd.tar.gz
Hi,
the logs are quite interesting.
You try to log in as user e2052982 which SSSD found as
CN=E2052982,OU=Staff,OU=School Users,DC=orange,DC=schools,DC=internal
which has the userPrincipalName attribute set to
peter.de.groot(a)EDUCATION.WA.EDU.AU. The principal is used by SSSD for
the first attempt to get a Kerberos TGT from an AD DC and to
authenticate the use
Getting initial credentials for
peter.de.groot\@EDUCATION.WA.EDU.AU(a)ORANGE.SCHOOLS.INTERNAL".
For this principal the AD DC returns a salt as
Selected etype info: etype aes256-cts, salt
"ORANGE.SCHOOLS.INTERNALpeter.de.groot", params ""
The Kerberos ticket is then issued for E2052982(a)ORANGE.SCHOOLS.INTERNAL
the expected canonical principal (which SSSD would have used if there
was not userPrincipalName attribute defined for the user.
SSSD stores the canonical principal in its cache as well so that
upcoming authentications can use this principal directly.
But when you authenticate for a second time and this principal is used:
Getting initial credentials for
E2052982\@ORANGE.SCHOOLS.INTERNAL(a)ORANGE.SCHOOLS.INTERNAL
the AD DC returns the salt as
Selected etype info: etype aes256-cts, salt
"ORANGE.SCHOOLS.INTERNALhoste4182s01sv023.orange.schools.internal", params
""
which is the expected salt for the host
e4182s01sv023.orange.schools.internal but not for a user.
Can you check if
kinit E2052982(a)ORANGE.SCHOOLS.INTERNAL
and
kinit -E -C E2052982(a)ORANGE.SCHOOLS.INTERNAL
work as expected? In that case it would be nice to see the full output
of
KRB5_TRACE=/dev/stdout kinit .....
of the workings case(s) and /etc/krb5.conf.
bye,
Sumit
>
> Please help .. driving me insane :-)
>
> Peter
>
>
> root@e4182s01sv025:/etc/sssd# more sssd.conf
>
> [sssd]
> domains = orange.schools.internal
> config_file_version = 2
> services = nss, pam ,ifp, sudo
> default_domain_suffix = ORANGE.SCHOOLS.INTERNAL
>
> [domain/orange.schools.internal]
> ad_domain = orange.schools.internal
> krb5_realm = ORANGE.SCHOOLS.INTERNAL
> realmd_tags = manages-system joined-with-adcli
> cache_credentials = True
> id_provider = ad
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> ldap_id_mapping = True
> use_fully_qualified_names = True
> fallback_homedir = /home/%d/%u
> access_provider = ad
> ad_gpo_access_control = permissive
> root@e4182s01sv025:/etc/sssd#
>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...