SSSD with different AD UPN Suffixes

[Eugene Peregudov]

Hi,

I'm trying to authenticate Active Directory users with different UPN  
suffixes on my Linux machine.
As described in article (http://jhrozek.livejournal.com/3019.html) SSSD  
should support for enterprise logins:
"some users in AD might use a different Kerberos Principal suffix than the  
default one".

I have two users with different UPN - [e-mail] and  
[e-mail]

#getent passwd [e-mail]

returns valid user entry, but

#getent passwd [e-mail]

returns nothing...

What's wrong? Can anyone help me with this issue? Thanks!

Target system:
Red Hat Enterprise Linux Server release 7.0 (Maipo)
host1.domain.example.com 3.10.0-123.13.2.el7.x86_64 x86_64 x86_64 x86_64  
GNU/Linux
sssd-1.11.2-68.el7_0.6.x86_64
---------------------------------------------------------------
Active Directory Domain:
schema:  2008 R2
tld:     domain.example.com
---------------------------------------------------------------
Linux machine joined AD using command:
#adcli join domain.example.com -U admin -S dc1.domain.example.com -H  
host1.domain.example.com -v -W
---------------------------------------------------------------
sssd.conf:

[sssd]
config_file_version = 2
services = nss, pam
domains = DOMAIN.EXAMPLE.COM

[nss]

[pam]

[domain/DOMAIN.EXAMPLE.COM]
  debug_level = 10
  id_provider = ad
  auth_provider = ad
  chpass_provider = ad
  access_provider = ad

ad_domain = domain.example.com
  ad_server = dc1.domain.example.com,10.0.0.2
  ad_hostname = host1.domain.example.com
  ldap_id_mapping = false
  ldap_schema = rfc2307
  krb5_use_enterprise_principal = true
  enumerate = false
  entry_cache_timeout = 60
  fallback_homedir = /home/org/users/%u
  shell_fallback = /bin/false
  dyndns_update = true
---------------------------------------------------------------
krb5.conf:

[libdefaults]
  dns_lookup_realm = false
  ticket_lifetime = 24h
  renew_lifetime = 7d
  forwardable = true
  rdns = false
  default_realm = DOMAIN.EXAMPLE.COM
  default_ccache_name = KEYRING:persistent:%{uid}

dns_lookup_kdc = false
[realms]

DOMAIN.EXAMPLE.COM = {
   kdc = dc1.domain.example.com
   kdc = 10.0.0.2
   admin_server = dc1.domain.example.com
   admin_server = 10.0.0.2
   default_domain = domain.example.com
}

[domain_realm]
  .domain.example.com = DOMAIN.EXAMPLE.COM
   domain.example.com = DOMAIN.EXAMPLE.COM

[appdefaults]
pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
}
---------------------------------------------------------------
sssd_DOMAIN.EXAMPLE.COM.log:

[sbus_dispatch] (0x4000): dbus conn: 0x7f75d0504770
[sbus_dispatch] (0x4000): Dispatching.
[sbus_message_handler] (0x4000): Received SBUS method [ping]
[sbus_dispatch] (0x4000): dbus conn: 0x7f75d0519b20
[sbus_dispatch] (0x4000): Dispatching.
[sbus_message_handler] (0x4000): Received SBUS method [getDomains]
[be_get_subdomains] (0x0400): Got get subdomains  
[forced][department.example.com]
[be_queue_request] (0x4000): Queue is empty, running request immediately.
[be_queue_request] (0x4000): Adding request to queue.
[sdap_id_op_connect_step] (0x4000): reusing cached connection
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with  
[objectclass=domain][DC=domain,DC=example,DC=com].
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID]
[sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 11
[sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],  
ops[0x7f75d052de50], ldap[0x7f75d0521980]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
[sdap_parse_entry] (0x4000): OriginalDN: [DC=domain,DC=example,DC=com].
[sdap_parse_range] (0x2000): No sub-attributes for [objectSid]
[sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],  
ops[0x7f75d052de50], ldap[0x7f75d0521980]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg  
set
[ad_master_domain_next_done] (0x0400): Found SID  
[S-1-5-21-1505972566-2156897661-2636268315].
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with  
[(&(DnsDomain=domain.example.com)(NtVer=\14\00\00\00))][].
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [netlogon]
[sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 12
[sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],  
ops[0x7f75d0530150], ldap[0x7f75d0521980]
[sdap_process_result] (0x2000): Trace: ldap_result found nothing!
[sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],  
ops[0x7f75d0530150], ldap[0x7f75d0521980]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
[sdap_parse_entry] (0x4000): OriginalDN: [].
[sdap_parse_range] (0x2000): No sub-attributes for [netlogon]
[sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],  
ops[0x7f75d0530150], ldap[0x7f75d0521980]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg  
set
[ad_master_domain_netlogon_done] (0x0400): Found flat name [DOMAIN].
[ad_master_domain_netlogon_done] (0x0400): Found forest  
[domain.example.com].
[ad_subdomains_master_dom_done] (0x0400): Connected to forest root,  
looking up child domains..
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with  
[(&(objectclass=trustedDomain)(trustType=2)(!(msDS-TrustForestTrustInfo=*)))][DC=domain,DC=example,DC=com].
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [flatName]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustPartner]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs:  
[securityIdentifier]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustType]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustAttributes]
[sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 13
[sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],  
ops[0x7f75d052e870], ldap[0x7f75d0521980]
[sdap_process_result] (0x2000): Trace: ldap_result found nothing!
[sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],  
ops[0x7f75d052e870], ldap[0x7f75d0521980]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
[sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],  
ops[0x7f75d052e870], ldap[0x7f75d0521980]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
[sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],  
ops[0x7f75d052e870], ldap[0x7f75d0521980]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
[sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],  
ops[0x7f75d052e870], ldap[0x7f75d0521980]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg  
set
[sdap_id_op_done] (0x4000): releasing operation connection
[ad_subdomains_get_slave_domain_done] (0x1000): There are no changes
[get_subdomains_callback] (0x0400): Backend returned: (0, 0, <NULL>)  
[Success]
[be_queue_next_request] (0x4000): Request queue is empty.
[sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],  
ops[(nil)], ldap[0x7f75d0521980]
[sdap_process_result] (0x2000): Trace: ldap_result found nothing!
[be_ptask_execute] (0x0400): Task [Cleanup of DOMAIN.EXAMPLE.COM]:  
executing task, timeout 10800 seconds
---------------------------------------------------------------

[Sumit Bose]

On Tue, Feb 03, 2015 at 04:17:39PM +0600, Eugene Peregudov wrote:
> Hi,
>
> I'm trying to authenticate Active Directory users with different UPN
> suffixes on my Linux machine.
> As described in article (http://jhrozek.livejournal.com/3019.html) SSSD
> should support for enterprise logins:
> "some users in AD might use a different Kerberos Principal suffix than the
> default one".
>
> I have two users with different UPN - [e-mail] and
> [e-mail]
>
> #getent passwd [e-mail]
>
> returns valid user entry, but
>
> #getent passwd [e-mail]
>
> returns nothing...
>
> What's wrong? Can anyone help me with this issue? Thanks!

Can you send the related sssd_nss logs with debug_level 10 as well?

bye,
Sumit
> Target system:
> Red Hat Enterprise Linux Server release 7.0 (Maipo)
> host1.domain.example.com 3.10.0-123.13.2.el7.x86_64 x86_64 x86_64 x86_64
> GNU/Linux
> sssd-1.11.2-68.el7_0.6.x86_64
>
> Active Directory Domain:
> schema:  2008 R2
> tld:     domain.example.com
>
> Linux machine joined AD using command:
> #adcli join domain.example.com -U admin -S dc1.domain.example.com -H
> host1.domain.example.com -v -W
>
> sssd.conf:
>
> [sssd]
> config_file_version = 2
> services = nss, pam
> domains = DOMAIN.EXAMPLE.COM
>
> [nss]
>
> [pam]
>
> [domain/DOMAIN.EXAMPLE.COM]
>  debug_level = 10
>  id_provider = ad
>  auth_provider = ad
>  chpass_provider = ad
>  access_provider = ad
>
> ad_domain = domain.example.com
>  ad_server = dc1.domain.example.com,10.0.0.2
>  ad_hostname = host1.domain.example.com
>  ldap_id_mapping = false
>  ldap_schema = rfc2307
>  krb5_use_enterprise_principal = true
>  enumerate = false
>  entry_cache_timeout = 60
>  fallback_homedir = /home/org/users/%u
>  shell_fallback = /bin/false
>  dyndns_update = true
>
> krb5.conf:
>
> [libdefaults]
>  dns_lookup_realm = false
>  ticket_lifetime = 24h
>  renew_lifetime = 7d
>  forwardable = true
>  rdns = false
>  default_realm = DOMAIN.EXAMPLE.COM
>  default_ccache_name = KEYRING:persistent:%{uid}
>
> dns_lookup_kdc = false
> [realms]
>
> DOMAIN.EXAMPLE.COM = {
>   kdc = dc1.domain.example.com
>   kdc = 10.0.0.2
>   admin_server = dc1.domain.example.com
>   admin_server = 10.0.0.2
>   default_domain = domain.example.com
> }
>
> [domain_realm]
>  .domain.example.com = DOMAIN.EXAMPLE.COM
>   domain.example.com = DOMAIN.EXAMPLE.COM
>
> [appdefaults]
> pam = {
>   debug = false
>   ticket_lifetime = 36000
>   renew_lifetime = 36000
>   forwardable = true
>   krb4_convert = false
> }
>
> sssd_DOMAIN.EXAMPLE.COM.log:
>
> [sbus_dispatch] (0x4000): dbus conn: 0x7f75d0504770
> [sbus_dispatch] (0x4000): Dispatching.
> [sbus_message_handler] (0x4000): Received SBUS method [ping]
> [sbus_dispatch] (0x4000): dbus conn: 0x7f75d0519b20
> [sbus_dispatch] (0x4000): Dispatching.
> [sbus_message_handler] (0x4000): Received SBUS method [getDomains]
> [be_get_subdomains] (0x0400): Got get subdomains
> [forced][department.example.com]
> [be_queue_request] (0x4000): Queue is empty, running request immediately.
> [be_queue_request] (0x4000): Adding request to queue.
> [sdap_id_op_connect_step] (0x4000): reusing cached connection
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> [objectclass=domain][DC=domain,DC=example,DC=com].
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID]
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 11
> [sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],
> ops[0x7f75d052de50], ldap[0x7f75d0521980]
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
> [sdap_parse_entry] (0x4000): OriginalDN: [DC=domain,DC=example,DC=com].
> [sdap_parse_range] (0x2000): No sub-attributes for [objectSid]
> [sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],
> ops[0x7f75d052de50], ldap[0x7f75d0521980]
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
> [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
> set
> [ad_master_domain_next_done] (0x0400): Found SID
> [S-1-5-21-1505972566-2156897661-2636268315].
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> [(&(DnsDomain=domain.example.com)(NtVer=\14\00\00\00))][].
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [netlogon]
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 12
> [sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],
> ops[0x7f75d0530150], ldap[0x7f75d0521980]
> [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
> [sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],
> ops[0x7f75d0530150], ldap[0x7f75d0521980]
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
> [sdap_parse_entry] (0x4000): OriginalDN: [].
> [sdap_parse_range] (0x2000): No sub-attributes for [netlogon]
> [sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],
> ops[0x7f75d0530150], ldap[0x7f75d0521980]
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
> [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
> set
> [ad_master_domain_netlogon_done] (0x0400): Found flat name [DOMAIN].
> [ad_master_domain_netlogon_done] (0x0400): Found forest
> [domain.example.com].
> [ad_subdomains_master_dom_done] (0x0400): Connected to forest root, looking
> up child domains..
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=trustedDomain)(trustType=2)(!(msDS-TrustForestTrustInfo=*)))][DC=domain,DC=example,DC=com].
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [flatName]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustPartner]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [securityIdentifier]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustType]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustAttributes]
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 13
> [sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],
> ops[0x7f75d052e870], ldap[0x7f75d0521980]
> [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
> [sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],
> ops[0x7f75d052e870], ldap[0x7f75d0521980]
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
> [sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],
> ops[0x7f75d052e870], ldap[0x7f75d0521980]
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
> [sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],
> ops[0x7f75d052e870], ldap[0x7f75d0521980]
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
> [sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],
> ops[0x7f75d052e870], ldap[0x7f75d0521980]
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
> [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
> set
> [sdap_id_op_done] (0x4000): releasing operation connection
> [ad_subdomains_get_slave_domain_done] (0x1000): There are no changes
> [get_subdomains_callback] (0x0400): Backend returned: (0, 0, <NULL>)
> [Success]
> [be_queue_next_request] (0x4000): Request queue is empty.
> [sdap_process_result] (0x2000): Trace: sh[0x7f75d05225d0], connected[1],
> ops[(nil)], ldap[0x7f75d0521980]
> [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
> [be_ptask_execute] (0x0400): Task [Cleanup of DOMAIN.EXAMPLE.COM]: executing
> task, timeout 10800 seconds
>
> -- 
> With best regards, Eugene JONIK Peregudov
> mailto: [e-mail]
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Eugene Peregudov]

Sumit Bose  писал(а) в своём письме Tue, 03 Feb 2015  
16:56:40 +0600:
> On Tue, Feb 03, 2015 at 04:17:39PM +0600, Eugene Peregudov wrote:
> > Hi,
> >
> > I'm trying to authenticate Active Directory users with different UPN
> > suffixes on my Linux machine.
> > As described in article (http://jhrozek.livejournal.com/3019.html) SSSD
> > should support for enterprise logins:
> > "some users in AD might use a different Kerberos Principal suffix than  
> > the
> > default one".
> >
> > I have two users with different UPN - [e-mail] and
> > [e-mail]
> >
> > #getent passwd [e-mail]
> >
> > returns valid user entry, but
> >
> > #getent passwd [e-mail]
> >
> > returns nothing...
> >
> > What's wrong? Can anyone help me with this issue? Thanks!
>
> Can you send the related sssd_nss logs with debug_level 10 as well?

Thanks for answer!
sssd_nss.log is empty with specified debug_level 10 :(

[Sumit Bose]

On Wed, Feb 04, 2015 at 12:18:44PM +0600, Eugene Peregudov wrote:
> Sumit Bose  писал(а) в своём письме Tue, 03 Feb 2015
> 16:56:40 +0600:
> > On Tue, Feb 03, 2015 at 04:17:39PM +0600, Eugene Peregudov wrote:
> > > Hi,
> > >
> > > I'm trying to authenticate Active Directory users with different UPN
> > > suffixes on my Linux machine.
> > > As described in article (http://jhrozek.livejournal.com/3019.html) SSSD
> > > should support for enterprise logins:
> > > "some users in AD might use a different Kerberos Principal suffix than
> > > the
> > > default one".
> > >
> > > I have two users with different UPN - [e-mail] and
> > > [e-mail]
> > >
> > > #getent passwd [e-mail]
> > >
> > > returns valid user entry, but
> > >
> > > #getent passwd [e-mail]
> > >
> > > returns nothing...
> > >
> > > What's wrong? Can anyone help me with this issue? Thanks!
> >
> > Can you send the related sssd_nss logs with debug_level 10 as well?
>
> Thanks for answer!
> sssd_nss.log is empty with specified debug_level 10 :(

You have to set it explicitly in the [nss] section.

HTH

bye,
Sumit
> -- 
> With best regards, Eugene JONIK Peregudov
> mailto: [e-mail]
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Eugene Peregudov]

Sumit Bose  писал(а) в своём письме Wed, 04 Feb 2015  
14:09:05 +0600:
> On Wed, Feb 04, 2015 at 12:18:44PM +0600, Eugene Peregudov wrote:
> > Sumit Bose  писал(а) в своём письме Tue, 03 Feb 2015
> > 16:56:40 +0600:
> > > On Tue, Feb 03, 2015 at 04:17:39PM +0600, Eugene Peregudov wrote:
> > > > Hi,
> > > >
> > > > I'm trying to authenticate Active Directory users with different UPN
> > > > suffixes on my Linux machine.
> > > > As described in article (http://jhrozek.livejournal.com/3019.html)
> >
> > SSSD
> > > > should support for enterprise logins:
> > > > "some users in AD might use a different Kerberos Principal suffix than
> > > > the
> > > > default one".
> > > >
> > > > I have two users with different UPN - [e-mail] and
> > > > [e-mail]
> > > >
> > > > #getent passwd [e-mail]
> > > >
> > > > returns valid user entry, but
> > > >
> > > > #getent passwd [e-mail]
> > > >
> > > > returns nothing...
> > > >
> > > > What's wrong? Can anyone help me with this issue? Thanks!
> > >
> > > Can you send the related sssd_nss logs with debug_level 10 as well?
> >
> > Thanks for answer!
> > sssd_nss.log is empty with specified debug_level 10 :(
>
> You have to set it explicitly in the [nss] section.

sssd_nss.log with debug_level 10:
--------------------------------------
[get_client_cred] (0x4000): Client creds: euid[0] egid[0] pid[46642].
[reset_idle_timer] (0x4000): Idle timer re-set for client  
[0x7f96a099c440][20]
[accept_fd_handler] (0x0400): Client connected!
[reset_idle_timer] (0x4000): Idle timer re-set for client  
[0x7f96a099c440][20]
[sss_cmd_get_version] (0x0200): Received client version [1].
[sss_cmd_get_version] (0x0200): Offered version [1].
[reset_idle_timer] (0x4000): Idle timer re-set for client  
[0x7f96a099c440][20]
[reset_idle_timer] (0x4000): Idle timer re-set for client  
[0x7f96a099c440][20]
[nss_cmd_getbynam] (0x0400): Running command [17] with input  
[[e-mail]].
[sss_dp_issue_request] (0x0400): Issuing request for  
[0x7f96a02027a0:[e-mail]]
[sss_dp_get_domains_msg] (0x0400): Sending get domains request for  
[DOMAIN.EXAMPLE.COM][forced][department.example.com]
[sbus_add_timeout] (0x2000): 0x7f96a099cde0
[sss_dp_internal_get_send] (0x0400): Entering request  
[0x7f96a02027a0:[e-mail]]
[sbus_remove_timeout] (0x2000): 0x7f96a099cde0
[sbus_dispatch] (0x4000): dbus conn: 0x7f96a0995fa0
[sbus_dispatch] (0x4000): Dispatching.
[sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code:  
0 errno: 0 error message: Success
[ldb] (0x4000): Added timed event "ltdb_callback": 0x7f96a09a0af0
[ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f96a09a0c20
[ldb] (0x4000): Running timer event 0x7f96a09a0af0 "ltdb_callback"
[ldb] (0x4000): Destroying timer event 0x7f96a09a0c20 "ltdb_timeout"
[ldb] (0x4000): Ending timer event 0x7f96a09a0af0 "ltdb_callback"
[ldb] (0x4000): Added timed event "ltdb_callback": 0x7f96a0996ea0
[ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f96a0996f60
[ldb] (0x4000): Running timer event 0x7f96a0996ea0 "ltdb_callback"
[ldb] (0x4000): Destroying timer event 0x7f96a0996f60 "ltdb_timeout"
[ldb] (0x4000): Ending timer event 0x7f96a0996ea0 "ltdb_callback"
[nss_cmd_getbynam_done] (0x0040): Invalid name received  
[[e-mail]]
[sss_dp_req_destructor] (0x0400): Deleting request:  
[0x7f96a02027a0:[e-mail]]
[reset_idle_timer] (0x4000): Idle timer re-set for client  
[0x7f96a099c440][20]
[reset_idle_timer] (0x4000): Idle timer re-set for client  
[0x7f96a099c440][20]
[client_recv] (0x0200): Client disconnected!
[client_destructor] (0x2000): Terminated client [0x7f96a099c440][20]
[sbus_dispatch] (0x4000): dbus conn: 0x7f96a0996ac0
[sbus_dispatch] (0x4000): Dispatching.
--------------------------------------

[Sumit Bose]

On Wed, Feb 04, 2015 at 03:03:29PM +0600, Eugene Peregudov wrote:
> Sumit Bose  писал(а) в своём письме Wed, 04 Feb 2015
> 14:09:05 +0600:
> > On Wed, Feb 04, 2015 at 12:18:44PM +0600, Eugene Peregudov wrote:
> > > Sumit Bose  писал(а) в своём письме Tue, 03 Feb 2015
> > > 16:56:40 +0600:
> > > > On Tue, Feb 03, 2015 at 04:17:39PM +0600, Eugene Peregudov wrote:
> > > > > Hi,
> > > > >
> > > > > I'm trying to authenticate Active Directory users with different UPN
> > > > > suffixes on my Linux machine.
> > > > > As described in article (http://jhrozek.livejournal.com/3019.html)
> > >
> > > SSSD
> > > > > should support for enterprise logins:
> > > > > "some users in AD might use a different Kerberos Principal suffix than
> > > > > the
> > > > > default one".
> > > > >
> > > > > I have two users with different UPN - [e-mail] and
> > > > > [e-mail]
> > > > >
> > > > > #getent passwd [e-mail]
> > > > >
> > > > > returns valid user entry, but
> > > > >
> > > > > #getent passwd [e-mail]
> > > > >
> > > > > returns nothing...
> > > > >
> > > > > What's wrong? Can anyone help me with this issue? Thanks!
> > > >
> > > > Can you send the related sssd_nss logs with debug_level 10 as well?
> > >
> > > Thanks for answer!
> > > sssd_nss.log is empty with specified debug_level 10 :(
> >
> > You have to set it explicitly in the [nss] section.
> sssd_nss.log with debug_level 10:

Thank you for the logs, I just realized that you use sssd-1.11, the UPN
lookups are a 1.12 feature. You can find a recent sssd-1.12 build in
Lukas' copr repo
https://copr-be.cloud.fedoraproject.org/results/lslebodn/sssd-1-12/epel-7-x8...
if you want to test this feature.

bye,
Sumit

[Eugene Peregudov]

Sumit Bose  писал(а) в своём письме Wed, 04 Feb 2015  
20:07:14 +0600:
> Thank you for the logs, I just realized that you use sssd-1.11, the UPN
> lookups are a 1.12 feature. You can find a recent sssd-1.12 build in
> Lukas' copr repo
> https://copr-be.cloud.fedoraproject.org/results/lslebodn/sssd-1-12/epel-7-x8...
> if you want to test this feature.

Thanks a lot!
I will try to test this feature with version 1.12 on the non-production  
machine later - need some kind of feedback about this? And, Sumit, can I  
hope, that version sssd 1.12 with this feature will be released in RHEL7.1?

[Sumit Bose]

On Thu, Feb 05, 2015 at 06:59:47PM +0600, Eugene Peregudov wrote:
> Sumit Bose  писал(а) в своём письме Wed, 04 Feb 2015
> 20:07:14 +0600:
> > Thank you for the logs, I just realized that you use sssd-1.11, the UPN
> > lookups are a 1.12 feature. You can find a recent sssd-1.12 build in
> > Lukas' copr repo
> > https://copr-be.cloud.fedoraproject.org/results/lslebodn/sssd-1-12/epel-7-x8...
> > if you want to test this feature.
>
> Thanks a lot!
> I will try to test this feature with version 1.12 on the non-production
> machine later - need some kind of feedback about this? And, Sumit, can I

Any feedback is welcome.
> hope, that version sssd 1.12 with this feature will be released in RHEL7.1?

I hope so too, since it was already included in the beta.

bye,
Sumit
> -- 
> With best regards, Eugene JONIK Peregudov
> mailto: [e-mail]
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

SSSD krb5_ccache

[Chris Petty]

In the near future i need to have my krb5 caches stored in a specific directory, so i was trying to set these defaults in sssd 1.11.6, on scientific linux 6.6 with krb5 1.10.3

Regardless of what i set, i always ended up with the cache files made in /tmp, with the default names

from sssd.conf:

krb5_ccachedir = /tmp/krb5cache
krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
> From the log:

(Fri Feb  6 10:36:03 2015) [sssd[be[dhe.duke.edu]]] [dp_get_options] (0x0400): Option krb5_ccachedir has value /tmp/krb5cache
(Fri Feb  6 10:36:03 2015) [sssd[be[dhe.duke.edu]]] [dp_get_options] (0x0400): Option krb5_ccname_template has value FILE:%d/krb5cc_%U_XXXXXX
(Fri Feb  6 10:36:03 2015) [sssd[be[dhe.duke.edu]]] [check_and_export_options] (0x0100): The credential ccache name template has been explicitly set in sssd.conf, it is recommended to set default_ccache_name in krb5.conf instead so that a system default is used

So it appears that things are set, correctly .. however when i get a ticket, its always in the default ( /tmp ):

[cmp12@dirac ~]$ klist 
Ticket cache: FILE:/tmp/krb5cc_119549_juVcIs5202

I looked into setting default_ccache_name, however that option is not available until krb5 1.11

Everything else is working as expected, any suggestions on making this work?

Thanks,
-Chris

SSSD krb5_ccache

[Sumit Bose]

On Fri, Feb 06, 2015 at 03:50:19PM +0000, Chris Petty wrote:
> In the near future i need to have my krb5 caches stored in a specific directory, so i was trying to set these defaults in sssd 1.11.6, on scientific linux 6.6 with krb5 1.10.3
>
> Regardless of what i set, i always ended up with the cache files made in /tmp, with the default names
>
> from sssd.conf:
>
> krb5_ccachedir = /tmp/krb5cache
> krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
>
> From the log:
> (Fri Feb  6 10:36:03 2015) [sssd[be[dhe.duke.edu]]] [dp_get_options] (0x0400): Option krb5_ccachedir has value /tmp/krb5cache
> (Fri Feb  6 10:36:03 2015) [sssd[be[dhe.duke.edu]]] [dp_get_options] (0x0400): Option krb5_ccname_template has value FILE:%d/krb5cc_%U_XXXXXX
> (Fri Feb  6 10:36:03 2015) [sssd[be[dhe.duke.edu]]] [check_and_export_options] (0x0100): The credential ccache name template has been explicitly set in sssd.conf, it is recommended to set default_ccache_name in krb5.conf instead so that a system default is used
>
> So it appears that things are set, correctly .. however when i get a ticket, its always in the default ( /tmp ):
>
> [cmp12@dirac ~]$ klist 
> Ticket cache: FILE:/tmp/krb5cc_119549_juVcIs5202
>
> I looked into setting default_ccache_name, however that option is not available until krb5 1.11
>
> Everything else is working as expected, any suggestions on making this work?

Please make sure that there is no session open for the user trying to
log in. SSSD tries to use the same credential cache for all sessions for
a given user.

HTH

bye,
Sumit
> Thanks,
> -Chris
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

SSSD krb5_ccache

[Chris Petty]

No other users were logged in, but it must be some other issue with my sssd config ( that hasn’t presented any obvious problems ) … i just tried it on a virtual machine with my older config ( access_provider = ldap ) and the cache directy was changed without issue.

will investigate further.

-Chris
> On Feb 6, 2015, at 12:18 PM, Sumit Bose  wrote:
>
> On Fri, Feb 06, 2015 at 03:50:19PM +0000, Chris Petty wrote:
> > In the near future i need to have my krb5 caches stored in a specific directory, so i was trying to set these defaults in sssd 1.11.6, on scientific linux 6.6 with krb5 1.10.3
> >
> > Regardless of what i set, i always ended up with the cache files made in /tmp, with the default names
> >
> > from sssd.conf:
> >
> > krb5_ccachedir = /tmp/krb5cache
> > krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
> >
> > From the log:
> > (Fri Feb  6 10:36:03 2015) [sssd[be[dhe.duke.edu]]] [dp_get_options] (0x0400): Option krb5_ccachedir has value /tmp/krb5cache
> > (Fri Feb  6 10:36:03 2015) [sssd[be[dhe.duke.edu]]] [dp_get_options] (0x0400): Option krb5_ccname_template has value FILE:%d/krb5cc_%U_XXXXXX
> > (Fri Feb  6 10:36:03 2015) [sssd[be[dhe.duke.edu]]] [check_and_export_options] (0x0100): The credential ccache name template has been explicitly set in sssd.conf, it is recommended to set default_ccache_name in krb5.conf instead so that a system default is used
> >
> > So it appears that things are set, correctly .. however when i get a ticket, its always in the default ( /tmp ):
> >
> > [cmp12@dirac ~]$ klist 
> > Ticket cache: FILE:/tmp/krb5cc_119549_juVcIs5202
> >
> > I looked into setting default_ccache_name, however that option is not available until krb5 1.11
> >
> > Everything else is working as expected, any suggestions on making this work?
>
> Please make sure that there is no session open for the user trying to
> log in. SSSD tries to use the same credential cache for all sessions for
> a given user.
>
> HTH
>
> bye,
> Sumit
> > Thanks,
> > -Chris
> > _______________________________________________
> > sssd-users mailing list
> > [e-mail]
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Eugene Peregudov]

Sumit Bose  писал(а) в своём письме Thu, 05 Feb 2015  
20:40:36 +0600:
> On Thu, Feb 05, 2015 at 06:59:47PM +0600, Eugene Peregudov wrote:
> > Sumit Bose  писал(а) в своём письме Wed, 04 Feb 2015
> > 20:07:14 +0600:
> > > Thank you for the logs, I just realized that you use sssd-1.11, the UPN
> > > lookups are a 1.12 feature. You can find a recent sssd-1.12 build in
> > > Lukas' copr repo
> > > https://copr-be.cloud.fedoraproject.org/results/lslebodn/sssd-1-12/epel-7-x8...
> > > if you want to test this feature.
> >
> > Thanks a lot!
> > I will try to test this feature with version 1.12 on the non-production
> > machine later - need some kind of feedback about this? And, Sumit, can I
>
> Any feedback is welcome.
> > hope, that version sssd 1.12 with this feature will be released in  
> > RHEL7.1?
>
> I hope so too, since it was already included in the beta.
>
> bye,
> Sumit

Issue resolved with sssd-1.12.2-58.el7.x86_64 on RHEL 7.1:

#getent passwd [e-mail]

and

#getent passwd [e-mail]

returns valid user entry both.