[Freeipa-users] sssd receives another uid/gid after disabled HBAC rule

Gregor Bregenzer gregor.bregenzer at gmail.com
Thu Sep 11 12:01:52 UTC 2014


Hello Sumit!

Ah, thanks alot! I was wondering why this worked on the FreeIPA server
(ipa1.linux.intern), but there i have SSSD 1.12. I will try with a
newer client on another client and join the FreeIPA domain.
About the original UID change problem: i will try that again and post
the correct logfiles with the appropriate loglevel.

Thanks!
Gregor

2014-09-11 12:58 GMT+02:00 Sumit Bose <sbose at redhat.com>:
> On Wed, Sep 10, 2014 at 08:19:15AM +0200, Gregor Bregenzer wrote:
>> Hello Sumit,
>> i think maybe there is a different problem i just discovered by
>> accident. As stated in the first email, i have an AD trust with
>> FreeIPA that receives all POSIX attributes from AD, but i get
>> different values:
>> On the FreeIPA server that has the AD trust (ipa1.linux.intern) i get
>> the correct GID (=10000, this is the AD group linuxusers) that is set
>> in AD, but on the client (linux1.linux.intern) i get another one ( =
>> 10005):
>>
>> ipa1.linux.intern
>> ~~~~
>> [root at ipa1 httpd]# getent passwd user1 at aaa
>> user1 at aaa.intern:*:10005:
>> 10000:user1:/home/aaa.intern/user1:/bin/bash
>>
>> -bash-4.2$ id
>> uid=10005(user1 at aaa.intern) gid=10000(linuxusers at aaa.intern)
>> groups=10000(linuxusers at aaa.intern),1933000004(ad_users)
>> ~~~~
>>
>> linux1.linux.intern
>> ~~~~~~~~
>> [root at linux1 sssd]# getent passwd user1 at aaa
>> user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash
>>
>> [user1 at aaa.intern@linux1 ~]$ id
>> uid=10005(user1 at aaa.intern) gid=10005(user1 at aaa.intern)
>> Gruppen=10005(user1 at aaa.intern),1933000004(ad_users)
>
> Since you are using SSSD-1.9.x on the client this behaviour is expected.
> In this version SSSD could only handle users from a trusted AD domain as
> users with User Private Groups (UPG), hence POSIX UID and GID are the
> same. The additional group memberships are only available after the user
> logged in. For this the PAC from the Kerberos ticket is evaluated. But
> the PAC does not contain any information about POSIX attributes and only
> contains groups  the user is member of from the AD point of view. If
> user1 is not a member of the linuxuser AD group SSSD cannot resolve this
> membership.
>
> Nevertheless I think this is not related to the UID change you reported
> earlier.
>
> bye,
> Sumit
>
>>
>> Logfile on ipa1.linux.intern sssd_nss.log
>> (Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0400):
>> Running command [17] with input [user1 at aaa.intern].
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_parse_name_for_domains]
>> (0x0200): name 'user1 at aaa.intern' matched expression for domain
>> 'aaa.intern', user is user1                                          │
>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
>> Requesting info for [user1] from [aaa.intern]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str]
>> (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search]
>> (0x0100): Requesting info for [user1 at aaa.intern]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed
>> event "ltdb_callback": 0x7fe19e562700
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed
>> event "ltdb_timeout": 0x7fe19e562830
>>>> 03│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running
>> timer event 0x7fe19e562700 "ltdb_callback"
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying
>> timer event 0x7fe19e562830 "ltdb_timeout"
>>                                                                 │va
>> r/│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer
>> event 0x7fe19e562700 "ltdb_callback"
>>>>   │(Wed Sep 10 08:14:42 2014) [sssd[nss]] [check_cache] (0x0400):
>> Cached entry is valid, returning..
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search]
>> (0x0400): Returning info for user [user1 at aaa.intern]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000):
>> Idle timer re-set for client [0x7fe19e563d40][21]
>>>>
>> ----------
>> Logfile on linux1.linux.intern sssd_nss.log
>>
>> (Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_parse_name_for_domains]
>> (0x0200): name 'user1 at aaa' matched expression for domain 'aaa.intern',
>> user is user1                                                 │
>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam] (0x0100):
>> Requesting info for [user1] from [aaa.intern]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str]
>> (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search]
>> (0x0100): Requesting info for [user1 at aaa.intern]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed
>> event "ltdb_callback": 0x20e2c20
>>>> (W│
>>
>>>> 00│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed
>> event "ltdb_timeout": 0x20e2590
>>>> (W│
>>
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running
>> timer event 0x20e2c20 "ltdb_callback"
>>>> (W│
>>
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying
>> timer event 0x20e2590 "ltdb_timeout"
>>>> (W│
>>
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer
>> event 0x20e2c20 "ltdb_callback"
>>>> (W│
>>
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_issue_request]
>> (0x0400): Issuing request for [0x432730:1:user1 at aaa.intern]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_get_account_msg]
>> (0x0400): Creating request for [aaa.intern][4097][1][name=user1]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_add_timeout] (0x2000):
>> 0x20d72e0
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_internal_get_send]
>> (0x0400): Entering request [0x432730:1:user1 at aaa.intern]
>>>> 01│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_remove_timeout]
>> (0x2000): 0x20d72e0
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_dispatch] (0x4000):
>> dbus conn: 20DB0F0
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_dispatch] (0x4000):
>> Dispatching.
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000):
>> Got reply from Data Provider - DP error code: 0 errno: 0 error
>> message: Success
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str]
>> (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search]
>> (0x0100): Requesting info for [user1 at aaa.intern]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed
>> event "ltdb_callback": 0x20e8530
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed
>> event "ltdb_timeout": 0x20e85e0
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running
>> timer event 0x20e8530 "ltdb_callback"
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying
>> timer event 0x20e85e0 "ltdb_timeout"
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer
>> event 0x20e8530 "ltdb_callback"
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search]
>> (0x0400): Returning info for user [user1 at aaa.intern]
>>>> 02│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_req_destructor]
>> (0x0400): Deleting request: [0x432730:1:user1 at aaa.intern]
>>>> :/│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000):
>> Idle timer re-set for client [0x20e44a0][20]
>>>>   │(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000):
>> Idle timer re-set for client [0x20e44a0][20]
>>>> (W│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [client_recv] (0x0200):
>> Client disconnected!
>>                                                                    │/v
>> ar│(Wed Sep 10 08:14:42 2014) [sssd[nss]] [client_destructor]
>> (0x2000): Terminated client [0x20e44a0][20]
>>
>> ~~~~
>>
>>
>> I think i need to get this one right before the HBAC rule - right?
>>
>>
>> Here is my ipa1.linux.intern sssd.conf:
>> ~~~~~~~~~
>> [domain/linux.intern]
>> debug_level=9
>> cache_credentials = True
>> krb5_store_password_if_offline = True
>> ipa_domain = linux.intern
>> id_provider = ipa
>> auth_provider = ipa
>> access_provider = ipa
>> ipa_hostname = ipa1.linux.intern
>> chpass_provider = ipa
>> ipa_server = ipa1.linux.intern
>> ipa_server_mode = True
>> ldap_tls_cacert = /etc/ipa/ca.crt
>> [sssd]
>> debug_level=9
>> services = nss, sudo, pam, ssh, pac
>> config_file_version = 2
>> subdomains_provider = ipa
>> domains = linux.intern
>> [nss]
>> debug_level=9
>> homedir_substring = /home
>>
>> [pam]
>> debug_level=9
>> [sudo]
>>
>> [autofs]
>>
>> [ssh]
>>
>> [pac]
>> debug_level=9
>> [ifp]
>>
>> ~~~~~~~~~~~~~~
>>
>> Here's my linux1.linux.intern sssd.conf
>> ~~~~~
>> [domain/linux.intern]
>> debug_level=9
>> cache_credentials = False
>> krb5_store_password_if_offline = False
>> ipa_domain = linux.intern
>> id_provider = ipa
>> auth_provider = ipa
>> access_provider = ipa
>> ipa_hostname = linux1.linux.intern
>> chpass_provider = ipa
>> ipa_dyndns_update = True
>> ipa_server = _srv_, ipa1.linux.intern
>> ldap_tls_cacert = /etc/ipa/ca.crt
>> use_fully_qualified_domains = True
>> # For the SUDO integration
>> sudo_provider = ldap
>> ldap_uri = ldap://ipa1.linux.intern
>> ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern
>> ldap_sasl_mech = GSSAPI
>> ldap_sasl_authid = host/linux1.linux.intern
>> ldap_sasl_realm = LINUX.INTERN
>> krb5_server = ipa1.linux.intern
>>
>> [sssd]
>> debug_level=9
>> services = nss, pam, ssh, sudo
>> config_file_version = 2
>> #default_domain_suffix=aaa.intern
>> domains = linux.intern
>> [nss]
>> debug_level=9
>> override_homedir = /home/%u
>> override_shell = /bin/bash
>> [pam]
>> debug_level=9
>> [sudo]
>>
>> [autofs]
>>
>> [ssh]
>> debug_level=9
>> [pac]
>> debug_level=9
>>
>> ~~~~
>>
>>
>> I used the following command to create the AD trust:
>>
>>       ipa trust-add --type=ad aaa.intern --admin Administrator
>> --password --range-type ipa-ad-trust-posix
>>
>> Do you need any other debug information?
>>
>>
>> Thanks!
>> Gregor
>>
>> 2014-09-08 9:17 GMT+02:00 Sumit Bose <sbose at redhat.com>:
>> > On Sun, Sep 07, 2014 at 11:41:16PM +0200, Gregor Bregenzer wrote:
>> >> Hi!
>> >>
>> >> I have an AD trust with FreeIPA 4.0.1 and defined a HBAC rule for a
>> >> specific user group (=ad_users which is an posix group that has an
>> >> external group as member) to login on a specific client
>> >> (=linux1.linux.intern).
>> >>
>> >> The problem is: once i disable the rule and the AD user is not allowed
>> >> to login anymore, the user on the client gets another uid and gid via
>> >> sssd.
>> >>
>> >> I use the posix attributes from AD, which will get received by sssd perfectly.
>> >> The client is running on CentOS 6.5 and uses sssd 1.9.2.129.el6_5.4
>> >> AD domain = aaa.intern
>> >> IPA domain = linux.intern
>> >> AD-User: user1   (uid=1005,gid=10005)
>> >>
>> >> Here an example:
>> >> ----------------------------
>> >> 1.) disable the hbac rule and the default allow_all rule:
>> >> 2.) check the uid/gid on the client (=linux1.linux.intern) and it looks fine:
>> >>
>> >> [root at linux1 sssd]# getent passwd user1 at aaa
>> >> user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash
>> >>
>> >> 3.) Login with ssh to client as user1. It will be denied upon correct
>> >> password input and ssh sessions closes. Up until now everything as
>> >> expected. But now:
>> >>
>> >> 4.) check for the uid/gid on the client - something totally different.
>> >> It now also receives the Firstname and Lastname from AD, latter is
>> >> empty:
>> >>
>> >> [root at linux1 sssd]# getent passwd user1 at aaa
>> >> user1 at aaa.intern:*:11601:11601:user1:/home/user1 at aaa.intern:/bin/bash
>> >>
>> >> 5.) Enable the hbac rule and login works, but the unexpected uid/gid
>> >> stays the same:
>> >>
>> >> login as: user1 at aaa
>> >> user1 at aaa@192.168.0.100's password:
>> >> login as: user1 at aaa
>> >> user1 at aaa@192.168.0.100's password:
>> >> Last failed login: Sun Sep  7 23:19:49 CEST 2014 from 192.168.0.26 on ssh:notty
>> >> There were 2 failed login attempts since the last successful login.
>> >> Creating home directory for user1 at aaa.
>> >> Last login: Sun Sep  7 23:21:02 2014 from 192.168.0.26
>> >> [user1 at aaa.intern@linux1 ~]$ id
>> >> uid=11601(user1 at aaa.intern) gid=11601(user1 at aaa.intern)
>> >> Gruppen=11601(user1 at aaa.intern),1933000004(ad_users)
>> >> [user1 at aaa.intern@linux1 ~]$
>> >> ---------------------------------
>> >>
>> >> Anyone have a clue what might be the problem?
>> >
>> > I would expect some kind of collision, but to be sure I need the SSSD
>> > log files. Please try to reproduce the switch and send me the log file,
>> > if possilbe with debug_level=9.
>> >
>> > bye,
>> > Sumit
>> >
>> >>
>> >> Here's the sssd.conf:
>> >> [root at linux1 sssd]# cat /etc/sssd/sssd.conf
>> >> [domain/linux.intern]
>> >> debug_level=6
>> >> cache_credentials = False
>> >> krb5_store_password_if_offline = False
>> >> ipa_domain = linux.intern
>> >> id_provider = ipa
>> >> auth_provider = ipa
>> >> access_provider = ipa
>> >> ipa_hostname = linux1.linux.intern
>> >> chpass_provider = ipa
>> >> ipa_dyndns_update = True
>> >> ipa_server = _srv_, ipa1.linux.intern
>> >> ldap_tls_cacert = /etc/ipa/ca.crt
>> >> use_fully_qualified_domains = True
>> >> # For the SUDO integration
>> >> sudo_provider = ldap
>> >> ldap_uri = ldap://ipa1.linux.intern
>> >> ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern
>> >> ldap_sasl_mech = GSSAPI
>> >> ldap_sasl_authid = host/linux1.linux.intern
>> >> ldap_sasl_realm = LINUX.INTERN
>> >> krb5_server = ipa1.linux.intern
>> >> entry_cache_sudo_timeout = 30
>> >> [sssd]
>> >> debug_level=6
>> >> services = nss, pam, ssh, sudo
>> >> config_file_version = 2
>> >> default_domain_suffix=aaa.intern
>> >> domains = linux.intern
>> >> [nss]
>> >> debug_level=9
>> >> override_homedir = /home/%u
>> >> override_shell = /bin/bash
>> >> [pam]
>> >> debug_level=6
>> >> [sudo]
>> >> debug_level=6
>> >> [autofs]
>> >>
>> >> [ssh]
>> >> debug_level=6
>> >> [pac]
>> >>
>> >>
>> >>
>> >> Thanks!
>> >> Gregor
>> >>
>> >> --
>> >> Manage your subscription for the Freeipa-users mailing list:
>> >> https://www.redhat.com/mailman/listinfo/freeipa-users
>> >> Go To http://freeipa.org for more info on the project
>> >
>> > --
>> > Manage your subscription for the Freeipa-users mailing list:
>> > https://www.redhat.com/mailman/listinfo/freeipa-users
>> > Go To http://freeipa.org for more info on the project




More information about the Freeipa-users mailing list