[SSSD-users] Re: sssd-1.16.1 loses POSIX group mapped from AD trusted domain
> On 11 Apr 2018, at 17:26, a.miroshniche...@rtk-dc.ru wrote: > > Hi, > > We have AD-trusted FreeIPA environment. > I installed sssd-1.16.1 on IPA servers and client hosts. > Posix user group "ad_app_admins" mapped to app-admins@ADTrustedDomain. > Sometimes AD user fails to login on hosts. sssd can not see mapping. AD user > groups show correct for user, but POSIX user group lost. > > When login success: > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_eval_user_element] (0x1000): [16] groups for [ADuser@ADTrustedDomain] > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_eval_user_element] (0x0200): Skipping non-IPA group > name=group1@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb > ... > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_eval_user_element] (0x0200): Skipping non-IPA group > name=app-admins@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_eval_user_element] (0x1000): Added group [ad_app_admins] for user > [ADuser] > > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_debug_print] (0x2000): RULE [allow_admin_mgmt_hosts] > [ENABLED]: > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_debug_print] (0x2000): services: > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): services_names: > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): [sshd] > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): services_groups > (none) > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_debug_print] (0x2000): users: > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): users_names (none) > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): users_groups: > ... > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): > [ad_app_admins] > ... > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_debug_print] (0x2000): targethosts: > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): targethosts_names > (none) > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): targethosts_groups: > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): > [admin-mng-hosts] > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_debug_print] (0x2000): srchosts: > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_evaluate] (0x0100): ALLOWED by rule [allow_admin_mgmt_hosts]. > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [hbac_evaluate] (0x0100): hbac_evaluate() >] > sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] > [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule > [allow_admin_mgmt_hosts] > > > > When login failed: > sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] > [hbac_eval_user_element] (0x1000): [15] groups for [ADuser@ADTrustedDomain] OK, here the user is missing one group membership. But I’m not sure how to help you with this limited log snippet. Did you observe some pattern that could help us reproduce the issue locally? Can you share the log files? > sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] > [hbac_eval_user_element] (0x0200): Skipping non-IPA group > name=group1@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb > ... > sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]]
[SSSD-users] sssd-1.16.1 loses POSIX group mapped from AD trusted domain
Hi, We have AD-trusted FreeIPA environment. I installed sssd-1.16.1 on IPA servers and client hosts. Posix user group "ad_app_admins" mapped to app-admins@ADTrustedDomain. Sometimes AD user fails to login on hosts. sssd can not see mapping. AD user groups show correct for user, but POSIX user group lost. When login success: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x1000): [16] groups for [ADuser@ADTrustedDomain] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x0200): Skipping non-IPA group name=group1@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb ... sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x0200): Skipping non-IPA group name=app-admins@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x1000): Added group [ad_app_admins] for user [ADuser] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): RULE [allow_admin_mgmt_hosts] [ENABLED]: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): services: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): services_names: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): [sshd] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): services_groups (none) sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): users: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): users_names (none) sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): users_groups: ... sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): [ad_app_admins] ... sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): targethosts: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): targethosts_names (none) sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): targethosts_groups: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): [admin-mng-hosts] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): srchosts: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_evaluate] (0x0100): ALLOWED by rule [allow_admin_mgmt_hosts]. sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_evaluate] (0x0100): hbac_evaluate() >] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_admin_mgmt_hosts] When login failed: sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x1000): [15] groups for [ADuser@ADTrustedDomain] sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x0200): Skipping non-IPA group name=group1@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb ... sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x0200): Skipping non-IPA group name=app-admins@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb <- There is no message "Added group [ad_app_admins] for user [ADuser]" sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): RULE [allow_admin_mgmt_hosts] [ENABLED]: sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.d
[SSSD-users] Re: unexpected owner for credentials
On Tue, Apr 10, 2018 at 05:21:26PM +, Charles Hedrick wrote: > Are there any performance issues with having lots of views? The number of views does not matter much because each host will only use the view assigned to it. But you only need multiple views if a single user currently has different UIDs on different clients. bye, Sumit > > > On Apr 10, 2018, at 7:55 AM, Simo Sorce wrote: > > > > SSSD cares only about the users it detects by design. > > > > The solution is to use ID Views on IPA to change the users UIDs on those > > machines. Hving the same users in files and ipa with different UIDs is not > > going to go down well and messing with PAM is just going to mnake the system > > even more brittle. > > > > The proper migration is to remove users from /etc/passwd, and use an ID > > View to > > "correct" any posix data on the target machines, until you can rebuild new > > ones > > with the central names. > > > > Simo. > > > > On Mon, 2018-04-09 at 16:32 +, Charles Hedrick wrote: > >> I’m trying to support an odd configuration. > >> > >> We have an IPA system, which is used in the normal way for systems run by > >> staff. But we have hundreds of systems run by faculty and grad students. > >> I’d like to encourage them to integrate with our system. However their > >> usernames and UIDs don’t typically match ours. I don’t think there’s much > >> I can do about usernames. But I’d at least like to survive differing UIDs. > >> Kerberos and even NFS V4 don’t care about UIDs. > >> > >> So I set up sssd pointing to IPA, with access_provider = deny (meaning > >> only people accepted by pam_unix can login), and nsswitch.conf having > >> “files sss." If a user logins in with the Kerberos password they’re logged > >> in correctly, but they can’t access their own Kerberos credentials. > >> > >> Their logged in UID is the one in /etc/passwd, because login correctly > >> obeys nsswitch. But their Kerberos credentials are for the UID in IPA. > >> > >> I can change id_provider to proxy/files. But then the sss nsswitch map > >> doesn’t work. I need to get groups from IPA in order to interpret groups > >> on our Netapp. I’d like to get users from IPA when there isn’t an entry in > >> /etc/passwd, so that ls -l on the Netapp can interpret user names. > >> > >> So what I’d like is that when sssd creates Kerberos credentials, it uses > >> the same user that login is going to use, i.e. that it obeys nsswitch. Is > >> this a reasonable expectation? > >> > >> Going further, I’d like a way to do username mapping that will work with > >> both sssd and Kerberos. One approach would be to pay attention to the > >> username map in /etc/krb5.conf or idmapd.conf, since I’d have to put the > >> mapping in both (I think). > >> > >> ___ > >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org > >> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > > > -- > > Simo Sorce > > Sr. Principal Software Engineer > > Red Hat, Inc > > ___ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: Config for joining AD forest and Kerberos cross-domain authentication
On Tue, Apr 10, 2018 at 06:57:15PM +0200, Bastian Rosner wrote:
> Hi,
>
> I think I found the solution. After I realized that putting a .k5login file
> into $HOME results in a working cross-domain Kerberos authentication, a
> search on this ML revealed the following:
>
> Add this to krb5.conf:
> [plugins]
> localauth = {
> module=sssd:/usr/lib/x86_64-linux-gnu/sssd/modules/sssd_krb5_localauth_plugin.so
> enable_only = sssd
> }
Glad to hear that it is working for you now. I would suggest to remove
'enable_only = sssd' so that other schemes like .k5login files can be
used as well.
SSSD should automatically create a config snippet for this in
/var/lib/sss/pubconf/krb5.include.d/localauth_plugin and in Fedora/RHEL
/etc/krb5.conf starts with
includedir /var/lib/sss/pubconf/krb5.include.d/
to automatically include the snippet.
HTH
bye,
Sumit
>
>
>
> Cheers, Bastian
>
>
> Am 2018-04-09 16:49, schrieb Bastian Rosner:
> > Am 2018-04-09 16:35, schrieb Sumit Bose:
> > > On Fri, Apr 06, 2018 at 10:21:11PM +0200, Bastian Rosner wrote:
> > > > On 04/06/2018 09:59 PM, Jakub Hrozek wrote:
> > > > >
> > > > >
> > > > > > On 6 Apr 2018, at 17:54, Bastian Rosner wrote:
> > > > > >
> > > > > > Unfortunately, users from other domains can't use their Kerberos
> > > > > > ticket, only password works. These users are specifying their
> > > > > > domain on login.
> > > > >
> > > > > This all sounds like the issue is not on the SSSD level, but either
> > > > > the krb5.conf configuration might be perhaps missing the domain-realm
> > > > > mappings, but what you said next was interesting:
> > > > This is the krb5.conf for a host in one of the other domains. My
> > > > client
> > > > (both computer and user) is in sub1 and logs in to a host in sub2.
> > > > $ cat /etc/krb5.conf
> > > > [logging]
> > > > default = FILE:/var/log/krb5libs.log
> > > >
> > > > [libdefaults]
> > > > default_realm = SUB2.EXAMPLE.COM
> > > > dns_lookup_realm = true
> > > > dns_lookup_kdc = true
> > > > ticket_lifetime = 24h
> > > > renew_lifetime = 7d
> > > > forwardable = true
> > > > rdns = false
> > > >
> > > > Do I have to specify all domains in here? I thought the site/forest
> > > > discovery of sssd-ad should take care of all the other trusted
> > > > subdomains.
> > > >
> > > > > > Surprisingly, once logged in after authenticating with a password,
> > > > > > foreign-domain users are able to issue a Kerberos ticket with kinit
> > > > > > if they specify username@FQDN
> > > > >
> > > > > Hmm, are you saying that if you log in with a password you don’t get
> > > > > a TGT?
> > > >
> > > > Actually I do get a ticket after a logging in using password:
> > > > $ klist
> > > > Ticket cache: FILE:/tmp/krb5cc_94821677_hr943p
> > > > Default principal: b...@sub1.example.com
> > > >
> > > > Valid starting Expires Service principal
> > > > 04/06/2018 16:09:54 04/07/2018 02:09:54
> > > > krbtgt/sub1.example@sub1.example.com
> > > > renew until 04/13/2018 16:09:54
> > > >
> > > > This ticket does not work on sub2 hosts but can be used for
> > > > gssapi-with-mic
> > > > based authentication in sub1.
> > >
> > > The authentication part is completely handled on the SSH level here. I
> > > would first check on the client (I guess it is a Windows
> > > workstation) if
> > > you got a service ticket for the Linux host after trying to
> > > authenticate
> > > with the SSH client (putty?). You can check this by calling
> > > 'klist.exe'
> > > in the command shell or power shell. You should see a principal like
> > > 'host/fqdn.of.the.linux.cli...@sub2.example.com' (if the client is
> > > joined to SUB2.EXAMPLE.COM).
> >
> > Clients are Linux and users can receive tickets for the local domain
> > and can also use these tickets for authentication on the local domain.
> > On the same domain, Kerberos-auth works.
> > Cross-domain, Kerberos-auth does not work.
> >
> >
> > > If the host/... principal is shown by klist there might be a user name
> > > to principal mapping issue on the client. Have you tried to use the
> > > fully-qualified user name 'b...@sub1.example.com' on the SSH client?
> >
> > That was the first thing we checked since it is so obvious.
> > Without using the @domain part, not even password-based authentication
> > works across domains.
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
