[SSSD-users] Re: Intermittent SSH authentication failures: SSSD+AD+PAM+Duo
On Wed, Jan 16, 2019 at 05:02:44PM -0800, Jordan Castillo wrote: > I actually have a followup to this already and it seems that I'm seeing > segfaults and service restarts around the times of these failed attempts. Which package version of SSSD are you using? Please make sure all required libraries are updated to the latest versions, especially libtalloc, libtdb, libtevent and libldb. HTH bye, Sumit > > Here is a better bad login attempt sssd_domain.com.log log, at level 0x1310: > > ``` > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [dp_get_account_info_handler] (0x0200): Got request for > [0x3][BE_REQ_INITGROUPS][name=jsm...@mydomain.com] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] [sss_domain_get_state] > (0x1000): Domain mydomain.com is Active > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] [sss_domain_get_state] > (0x1000): Domain mydomain.com is Active > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] [sss_domain_get_state] > (0x1000): Domain mydomain.com is Active > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sshPublicKeys] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [userCertificate;binary] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [mail] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] [sdap_parse_entry] > (0x1000): OriginalDN: [CN=John Smith,CN=Users,DC=mydomain,DC=com]. > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_add_references] (0x1000): Additional References: > ldap://mydomain.com/CN=Configuration,DC=mydomain,DC=com > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] [sss_domain_get_state] > (0x1000): Domain mydomain.com is Active > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] [sysdb_set_entry_attr] > (0x0200): Entry [name=jsm...@mydomain.com,cn=users,cn=mydomain.com,cn=sysdb] > has set [ts_cache] attrs. > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [tokenGroups] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] [sdap_parse_entry] > (0x1000): OriginalDN: [CN=John Smith,CN=Users,DC=mydomain,DC=com]. > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_ad_tokengroups_get_posix_members] (0x1000): Processing membership SID > [S-1-5-32-545] > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] [sss_domain_get_state] > (0x1000): Domain mydomain.com is Active > (Wed Jan 16 16:07:35 2019) [sssd[be[mydomain.com]]] > [sdap_ad_tokengroups_get_posix_members] (0x1000): Processing membership SID > [S-1-5-32-544] >
[SSSD-users] Re: Intermittent SSH authentication failures: SSSD+AD+PAM+Duo
Here are my log files for both the good and bad attempts. <> ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org
[SSSD-users] Intermittent SSH authentication failures: SSSD+AD+PAM+Duo
Hello, I am facing a very confounding issue with my SSSD/AD integration on CentOS 7. I am configured to use SSSD and Active Directory to authenticate SSH logins. Users use an SSH key stored in an Active Directory attribute to log in, followed by a Duo 2FA prompt. SSH is configured to check the key, then provide the Duo prompt via PAM. About 80% of the time this works correctly. The other 20% of the time, users see a long hang (approx 1-2 minutes) after the Duo prompt, followed by a generic "Authentication failure" error. This with login attempts from the same user, on the same host, logging in to the same server, authenticating against the same AD DC. I am having a hard time discovering the underlying issue causing this problem. From my sshd logs, the best error I seem to have found is this: Jan 16 11:33:49 cerberusvm sshd[4201]: debug3: PAM: do_pam_account pam_acct_mgmt = 9 (Authentication service cannot retrieve authentication info) Jan 16 11:33:49 cerberusvm sshd[4201]: debug3: ssh_msg_send: type 13 Jan 16 11:33:49 cerberusvm sshd[4197]: debug3: PAM: User account has expired Here is my relevant sshd_config: PasswordAuthentication no PubkeyAuthentication yes # Change to no to disable s/key passwords ChallengeResponseAuthentication yes AuthenticationMethods publickey,keyboard-interactive AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser root UseDNS no UsePAM yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no #KerberosUseKuserok yes # GSSAPI options GSSAPIAuthentication yes GSSAPICleanupCredentials no Here is my current sssd.conf file (I have been frequently experimenting with config changes here. Logins work, but the occasional failure occurs for reasons I cannot determine): [sssd] domains = mydomain.com config_file_version = 2 services = nss, pam, ssh [ssh] debug_level = 3 [domain/mydomain.com] debug_level = 3 ad_domain = mydomain.com ad_server = prodad1.mydomain.com ad_hostname = cerberusvm.mydomain.com dyndns_update = false krb5_realm = MYDOMAIN.COM realmd_tags = manages-system joined-with-samba cache_credentials = False krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = False use_fully_qualified_names = False fallback_homedir = /home/%u access_provider = ad id_provider = ad auth_provider = ad ldap_user_ssh_public_key = sshPublicKeys Here is my pam.d/system-auth: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid >= 1000 quiet_success authsufficientpam_sss.so forward_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= passwordsufficientpam_unix.so md5 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Here is my pam.d/sshd: #%PAM-1.0 auth required pam_sepermit.so auth required pam_env.so auth sufficient pam_duo.so auth required pam_deny.so auth include postlogin # Used with polkit to reauthorize users in remote sessions -auth optional pam_reauthorize.so prepare accountrequired pam_nologin.so accountinclude password-auth password include password-auth # pam_selinux.so close should be the first session rule sessionrequired pam_selinux.so close sessionrequired pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context sessionrequired pam_selinux.so open env_params sessionrequired pam_namespace.so sessionoptional pam_keyinit.so force revoke sessioninclude password-auth sessioninclude postlogin # Used with polkit to reauthorize users in remote sessions -session optional pam_reauthorize.so prepare From sssd's side, here is the error I tend to see that does not appear in a log from a working login: (Wed Jan 16 11:32:20 2019) [sssd[be[mydomain.com]]] [ad_check_gc_usability_search_done] (0x0080): Cannot get isMemberOfPartialAttributeSet(Wed Jan 16 11:32:20 2019) [sssd[be
[SSSD-users] Re: Understanding sssd cache
> -Message d'origine- > De : Jakub Hrozek [mailto:jhro...@redhat.com] > Envoyé : mercredi 16 janvier 2019 16:03 > À : sssd-users@lists.fedorahosted.org > Objet : [SSSD-users] Re: Understanding sssd cache > > On Wed, Jan 16, 2019 at 03:50:59PM +0100, Maupertuis Philippe wrote: > > > > > > > -Message d'origine- > > > De : Jakub Hrozek [mailto:jhro...@redhat.com] > > > Envoyé : mercredi 16 janvier 2019 15:24 > > > À : sssd-users@lists.fedorahosted.org > > > Objet : [SSSD-users] Re: Understanding sssd cache > > > > > > On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote: > > > > > > > > > > > > > -Message d'origine- > > > > > De : Lukas Slebodnik [mailto:lsleb...@redhat.com] > > > > > Envoyé : mercredi 16 janvier 2019 12:47 > > > > > À : End-user discussions about the System Security Services Daemon > > > > > Objet : [SSSD-users] Re: Understanding sssd cache > > > > > > > > > > On (16/01/19 09:14), Maupertuis Philippe wrote: > > > > > >Hi > > > > > >I am trying to find out how th sssd cache is being populated. > > > > > >I couldn't find much about it so I did some tests. > > > > > >It seems that with enumerate = true, the cache holds all the > information > > > > > needed as soon as sssd is started. > > > > > >With enumerate = false, the cache holds information about > someone > > > only > > > > > after his first connection. > > > > > >Is that right ? > > > > > >I would like to be sure that user's passwords are stored in the cache > but > > > > > couldn't find any way to verify this > > > > > >With sssctl user-show I can find if a user is in the cache but with > > > > > >no > > > details. > > > > > >With sssctl user-checks I get some information about the user but > > > nothing > > > > > about the password. > > > > > >By examining directly the cache with ldbsearch I don't find any > password > > > > > information either, only maybe shadowLastChange: with a number > which > > > I > > > > > don't understand. > > > > > >Is there any documentation about the cache management ? > > > > > > > > > > > > > > > > Hashed password is cached only after successful authentication. It is > not > > > > > rerieved by "getent passwd $user". > > > > > > > > > > sssd cache is internal cache and should not be used directly by user. > > > > I understand that and was looking at it only to try to understand how it > > > works. > > > > > > > > > May I know what do you want to achieve? > > > > When using regular ssh access the the ssh publickey is in the cache if > > > needed. > > > > A user who had not connected previously is able to connect even if the > > > backend is unreachable > > > > When using the console, we have to rely on the password. > > > > When something goes wrong (sshd down or network issue), there is a > high > > > probability that the user would connect to the console for the first time. > > > > So if there is no guarantee the login could be successful offline we > > > > need > to > > > have a local (shared) account to connect to the console. > > > > A shared account is a nightmare to manage and a sore point for audits, > we > > > would like to remove it. > > > > > > The sss_seed tool was meant as a way to mitigate this. > > If I understand it correctly to have only nominative account in place for > console login, each user would have to put his own password in the cache > before something goes wrong. > > Obviously it won't work in a large environment. > > So we can't rely on SSSD and its cache for console login, a local user is > mandatory. > > If you're going to orchestrate useradd for each local user, how is that > more difficult than sss_seed for each remote user? Maybe I am missing something but sss_seed requires a password. Only the user itself can provide a password for himself , even a temporary one otherwise he can pretend it was not him who did evil things. And sss_seed would be needed for all remote users. I just need one local user (and I have already root) for which I must manage the password according to the various security standards we are subject to. Managing the root password is not exactly a piece of cake, I was hoping to get rid of it. > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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- > us...@lists.fedorahosted.org !!!* "Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant ê
[SSSD-users] Re: Understanding sssd cache
On Wed, Jan 16, 2019 at 03:50:59PM +0100, Maupertuis Philippe wrote: > > > > -Message d'origine- > > De : Jakub Hrozek [mailto:jhro...@redhat.com] > > Envoyé : mercredi 16 janvier 2019 15:24 > > À : sssd-users@lists.fedorahosted.org > > Objet : [SSSD-users] Re: Understanding sssd cache > > > > On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote: > > > > > > > > > > -Message d'origine- > > > > De : Lukas Slebodnik [mailto:lsleb...@redhat.com] > > > > Envoyé : mercredi 16 janvier 2019 12:47 > > > > À : End-user discussions about the System Security Services Daemon > > > > Objet : [SSSD-users] Re: Understanding sssd cache > > > > > > > > On (16/01/19 09:14), Maupertuis Philippe wrote: > > > > >Hi > > > > >I am trying to find out how th sssd cache is being populated. > > > > >I couldn't find much about it so I did some tests. > > > > >It seems that with enumerate = true, the cache holds all the > > > > >information > > > > needed as soon as sssd is started. > > > > >With enumerate = false, the cache holds information about someone > > only > > > > after his first connection. > > > > >Is that right ? > > > > >I would like to be sure that user's passwords are stored in the cache > > > > >but > > > > couldn't find any way to verify this > > > > >With sssctl user-show I can find if a user is in the cache but with no > > details. > > > > >With sssctl user-checks I get some information about the user but > > nothing > > > > about the password. > > > > >By examining directly the cache with ldbsearch I don't find any > > > > >password > > > > information either, only maybe shadowLastChange: with a number which > > I > > > > don't understand. > > > > >Is there any documentation about the cache management ? > > > > > > > > > > > > > Hashed password is cached only after successful authentication. It is > > > > not > > > > rerieved by "getent passwd $user". > > > > > > > > sssd cache is internal cache and should not be used directly by user. > > > I understand that and was looking at it only to try to understand how it > > works. > > > > > > > May I know what do you want to achieve? > > > When using regular ssh access the the ssh publickey is in the cache if > > needed. > > > A user who had not connected previously is able to connect even if the > > backend is unreachable > > > When using the console, we have to rely on the password. > > > When something goes wrong (sshd down or network issue), there is a high > > probability that the user would connect to the console for the first time. > > > So if there is no guarantee the login could be successful offline we need > > > to > > have a local (shared) account to connect to the console. > > > A shared account is a nightmare to manage and a sore point for audits, we > > would like to remove it. > > > > The sss_seed tool was meant as a way to mitigate this. > If I understand it correctly to have only nominative account in place for > console login, each user would have to put his own password in the cache > before something goes wrong. > Obviously it won't work in a large environment. > So we can't rely on SSSD and its cache for console login, a local user is > mandatory. If you're going to orchestrate useradd for each local user, how is that more difficult than sss_seed for each remote user? ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org
[SSSD-users] Re: Understanding sssd cache
> -Message d'origine- > De : Jakub Hrozek [mailto:jhro...@redhat.com] > Envoyé : mercredi 16 janvier 2019 15:24 > À : sssd-users@lists.fedorahosted.org > Objet : [SSSD-users] Re: Understanding sssd cache > > On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote: > > > > > > > -Message d'origine- > > > De : Lukas Slebodnik [mailto:lsleb...@redhat.com] > > > Envoyé : mercredi 16 janvier 2019 12:47 > > > À : End-user discussions about the System Security Services Daemon > > > Objet : [SSSD-users] Re: Understanding sssd cache > > > > > > On (16/01/19 09:14), Maupertuis Philippe wrote: > > > >Hi > > > >I am trying to find out how th sssd cache is being populated. > > > >I couldn't find much about it so I did some tests. > > > >It seems that with enumerate = true, the cache holds all the information > > > needed as soon as sssd is started. > > > >With enumerate = false, the cache holds information about someone > only > > > after his first connection. > > > >Is that right ? > > > >I would like to be sure that user's passwords are stored in the cache but > > > couldn't find any way to verify this > > > >With sssctl user-show I can find if a user is in the cache but with no > details. > > > >With sssctl user-checks I get some information about the user but > nothing > > > about the password. > > > >By examining directly the cache with ldbsearch I don't find any password > > > information either, only maybe shadowLastChange: with a number which > I > > > don't understand. > > > >Is there any documentation about the cache management ? > > > > > > > > > > Hashed password is cached only after successful authentication. It is not > > > rerieved by "getent passwd $user". > > > > > > sssd cache is internal cache and should not be used directly by user. > > I understand that and was looking at it only to try to understand how it > works. > > > > > May I know what do you want to achieve? > > When using regular ssh access the the ssh publickey is in the cache if > needed. > > A user who had not connected previously is able to connect even if the > backend is unreachable > > When using the console, we have to rely on the password. > > When something goes wrong (sshd down or network issue), there is a high > probability that the user would connect to the console for the first time. > > So if there is no guarantee the login could be successful offline we need to > have a local (shared) account to connect to the console. > > A shared account is a nightmare to manage and a sore point for audits, we > would like to remove it. > > The sss_seed tool was meant as a way to mitigate this. If I understand it correctly to have only nominative account in place for console login, each user would have to put his own password in the cache before something goes wrong. Obviously it won't work in a large environment. So we can't rely on SSSD and its cache for console login, a local user is mandatory. > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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- > us...@lists.fedorahosted.org !!!* "Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!" ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org
[SSSD-users] Re: Understanding sssd cache
On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote: > > > > -Message d'origine- > > De : Lukas Slebodnik [mailto:lsleb...@redhat.com] > > Envoyé : mercredi 16 janvier 2019 12:47 > > À : End-user discussions about the System Security Services Daemon > > Objet : [SSSD-users] Re: Understanding sssd cache > > > > On (16/01/19 09:14), Maupertuis Philippe wrote: > > >Hi > > >I am trying to find out how th sssd cache is being populated. > > >I couldn't find much about it so I did some tests. > > >It seems that with enumerate = true, the cache holds all the information > > needed as soon as sssd is started. > > >With enumerate = false, the cache holds information about someone only > > after his first connection. > > >Is that right ? > > >I would like to be sure that user's passwords are stored in the cache but > > couldn't find any way to verify this > > >With sssctl user-show I can find if a user is in the cache but with no > > >details. > > >With sssctl user-checks I get some information about the user but nothing > > about the password. > > >By examining directly the cache with ldbsearch I don't find any password > > information either, only maybe shadowLastChange: with a number which I > > don't understand. > > >Is there any documentation about the cache management ? > > > > > > > Hashed password is cached only after successful authentication. It is not > > rerieved by "getent passwd $user". > > > > sssd cache is internal cache and should not be used directly by user. > I understand that and was looking at it only to try to understand how it > works. > > > May I know what do you want to achieve? > When using regular ssh access the the ssh publickey is in the cache if needed. > A user who had not connected previously is able to connect even if the > backend is unreachable > When using the console, we have to rely on the password. > When something goes wrong (sshd down or network issue), there is a high > probability that the user would connect to the console for the first time. > So if there is no guarantee the login could be successful offline we need to > have a local (shared) account to connect to the console. > A shared account is a nightmare to manage and a sore point for audits, we > would like to remove it. The sss_seed tool was meant as a way to mitigate this. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org
[SSSD-users] Re: Understanding sssd cache
> -Message d'origine- > De : Lukas Slebodnik [mailto:lsleb...@redhat.com] > Envoyé : mercredi 16 janvier 2019 12:47 > À : End-user discussions about the System Security Services Daemon > Objet : [SSSD-users] Re: Understanding sssd cache > > On (16/01/19 09:14), Maupertuis Philippe wrote: > >Hi > >I am trying to find out how th sssd cache is being populated. > >I couldn't find much about it so I did some tests. > >It seems that with enumerate = true, the cache holds all the information > needed as soon as sssd is started. > >With enumerate = false, the cache holds information about someone only > after his first connection. > >Is that right ? > >I would like to be sure that user's passwords are stored in the cache but > couldn't find any way to verify this > >With sssctl user-show I can find if a user is in the cache but with no > >details. > >With sssctl user-checks I get some information about the user but nothing > about the password. > >By examining directly the cache with ldbsearch I don't find any password > information either, only maybe shadowLastChange: with a number which I > don't understand. > >Is there any documentation about the cache management ? > > > > Hashed password is cached only after successful authentication. It is not > rerieved by "getent passwd $user". > > sssd cache is internal cache and should not be used directly by user. I understand that and was looking at it only to try to understand how it works. > May I know what do you want to achieve? When using regular ssh access the the ssh publickey is in the cache if needed. A user who had not connected previously is able to connect even if the backend is unreachable When using the console, we have to rely on the password. When something goes wrong (sshd down or network issue), there is a high probability that the user would connect to the console for the first time. So if there is no guarantee the login could be successful offline we need to have a local (shared) account to connect to the console. A shared account is a nightmare to manage and a sore point for audits, we would like to remove it. > > LS > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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- > us...@lists.fedorahosted.org !!!* "Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!" ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org
[SSSD-users] Re: SSSD with Kerberos for SPENGO ( Nginx + pam + sss + sss_krb )
On Wed, Jan 16, 2019 at 01:26:51PM +0100, Eugen Mayer wrote: > Hello, > > i am really struggling to understand if what i am trying to do is actually > something that is supported by SSD in that terms. > > I have a lab setup with a Windows Server 2012 with a konfigured KDC, DNS, NTP > .. keytab, spn. > > This setup already works for apache+mod_kerb_auth for both cases, > auto-negotiation of existing tickets. So i can do kinit + curl --negotiate on > a client and get pass the authentication. > > Now i am trying to replace apache with nginx with this case. I want to use > nginx_pam, and then forward this to sssd using pam_sss. > > My id_provider is ad, auth_provider is krb5, realm is KWTEST.LOCAL > > I see that the AD access works using GSSAPI authentication using the provided > keytab file, but when a client request though nginx is handled, i see > something that sssd is trying to lookup www-data@KWTEST.LOCAL out of any > reason. > > I would have expected that it uses the HOST requested by the client, like > HTTP/mywebservice.lan@KWTEST.LOCAL - in mod_auth_kerb one can set the SPN to > use, i am not sure how this is intended in sssd and that is my actual > question. > > - Can SSSD offer "negotiation" through pam ... nginx at all? (reusing active > client krb tokens) No, what you are looking for is GSSAPI support and it looks like https://github.com/stnoonan/spnego-http-auth-nginx-module might be a suitable module. HTH bye, Sumit > - What SPN is used when pam calls SSSD? > > I hope i could explain this at least a little ;/ > > Thank you > > Eugen > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org
[SSSD-users] SSSD with Kerberos for SPENGO ( Nginx + pam + sss + sss_krb )
Hello, i am really struggling to understand if what i am trying to do is actually something that is supported by SSD in that terms. I have a lab setup with a Windows Server 2012 with a konfigured KDC, DNS, NTP .. keytab, spn. This setup already works for apache+mod_kerb_auth for both cases, auto-negotiation of existing tickets. So i can do kinit + curl --negotiate on a client and get pass the authentication. Now i am trying to replace apache with nginx with this case. I want to use nginx_pam, and then forward this to sssd using pam_sss. My id_provider is ad, auth_provider is krb5, realm is KWTEST.LOCAL I see that the AD access works using GSSAPI authentication using the provided keytab file, but when a client request though nginx is handled, i see something that sssd is trying to lookup www-data@KWTEST.LOCAL out of any reason. I would have expected that it uses the HOST requested by the client, like HTTP/mywebservice.lan@KWTEST.LOCAL - in mod_auth_kerb one can set the SPN to use, i am not sure how this is intended in sssd and that is my actual question. - Can SSSD offer "negotiation" through pam ... nginx at all? (reusing active client krb tokens) - What SPN is used when pam calls SSSD? I hope i could explain this at least a little ;/ Thank you Eugen___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org
[SSSD-users] Re: Understanding sssd cache
On (16/01/19 09:14), Maupertuis Philippe wrote: >Hi >I am trying to find out how th sssd cache is being populated. >I couldn't find much about it so I did some tests. >It seems that with enumerate = true, the cache holds all the information >needed as soon as sssd is started. >With enumerate = false, the cache holds information about someone only after >his first connection. >Is that right ? >I would like to be sure that user's passwords are stored in the cache but >couldn't find any way to verify this >With sssctl user-show I can find if a user is in the cache but with no >details. >With sssctl user-checks I get some information about the user but nothing >about the password. >By examining directly the cache with ldbsearch I don't find any password >information either, only maybe shadowLastChange: with a number which I don't >understand. >Is there any documentation about the cache management ? > Hashed password is cached only after successful authentication. It is not rerieved by "getent passwd $user". sssd cache is internal cache and should not be used directly by user. May I know what do you want to achieve? LS ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org
[SSSD-users] Re: Understanding sssd cache
Ijcni - Původní zpráva - Od:"Maupertuis Philippe" Odesláno:16. 1. 2019 9:15 Komu:"sssd-users@lists.fedorahosted.org" Předmět:[SSSD-users] Understanding sssd cache Hi I am trying to find out how th sssd cache is being populated. I couldn’t find much about it so I did some tests. It seems that with enumerate = true, the cache holds all the information needed as soon as sssd is started. With enumerate = false, the cache holds information about someone only after his first connection. Is that right ? I would like to be sure that user’s passwords are stored in the cache but couldn’t find any way to verify this With sssctl user-show I can find if a user is in the cache but with no details. With sssctl user-checks I get some information about the user but nothing about the password. By examining directly the cache with ldbsearch I don’t find any password information either, only maybe shadowLastChange: with a number which I don’t understand. Is there any documentation about the cache management ? Regards Philippe !!!* "Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org
[SSSD-users] Understanding sssd cache
Hi I am trying to find out how th sssd cache is being populated. I couldn't find much about it so I did some tests. It seems that with enumerate = true, the cache holds all the information needed as soon as sssd is started. With enumerate = false, the cache holds information about someone only after his first connection. Is that right ? I would like to be sure that user's passwords are stored in the cache but couldn't find any way to verify this With sssctl user-show I can find if a user is in the cache but with no details. With sssctl user-checks I get some information about the user but nothing about the password. By examining directly the cache with ldbsearch I don't find any password information either, only maybe shadowLastChange: with a number which I don't understand. Is there any documentation about the cache management ? Regards Philippe !!!* "Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!" ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org
