quick top-post
I'll be on vacacation starting tomorrow and the whole next week. I hope
some of the other sssd developers can help you out.
tl;dr the public key should be set in ldap_user_ssh_public_key
Thank you. The tips did make difference.
Not at all.
But I'm really curious about the reasons behind SSSD failing to retrieve
the public key when deactivating subdomains_provider. In our case, as we
don't have subdomains but forest trusts which SSSD doesn't support,
we've got no reason having subdomains_provider activated to enumerate
them (the trusted forests). It would be interesting to know why forest
trusts are enumerated in the first place.
It would also be interesting to know which kind of servers that are
targeted for ldap_groups_use_matching_rule_in_chain and
ldap_initgroups_use_matching_rule_in_chain. I imagine
"follow-the-sun"-servers with quite some (need for authentication) load.
In any case I'll check if its really needed at this point.
Regards
Davor
On Thu, Aug 20, 2015 at 09:29:25PM +0200, Davor Vusir wrote:
>
>
> Jakub Hrozek skrev den 2015-08-20 13:20:
>> On Thu, Aug 20, 2015 at 12:40:07PM +0200, Davor Vusir wrote:
>>> Hi!
>>>
>>> We store our public ssh keys in AD user account (altSecurityIdentities).
>>> Red Hat release 6.6/sssd 1.11.6. Adding
>>
>
> We'll get there in due time.
>
> ~~~~~~~~~~~~~~~
>> 6.7 is out for some time with quite some enhancements.
>>
>>>
>>> subdomains_provider = none
>>>
>>
>> Why would you expect disabling subdomains provider to have any effect on
>> public keys retrieval?
>>
>
> I don't. I was quite suprised that it does.
>
>>> alone ends in not being able to get the public key but are asked for our AD
>>> user accounts password.
>>> Adding
>>>
>>> ldap_groups_use_matching_rule_in_chain = True
>>> ldap_initgroups_use_matching_rule_in_chain = True
>>>
>>> makes the logon time so long that it seems that SSSD forgets the content of
>>> the attribute altSecurityIdentities and we are asked for our AD user
>>> accounts password.
>>
>> So why do you add them?
>>
>
> "This option tells SSSD to take advantage of an Active Directory-specific
> feature which may speed up group lookup operations on deployments with
> complex or deep nested groups.
>
> In most common cases, it is best to leave this option disabled. It generally
> only provides a performance increase on very complex nestings."
>
> -
https://jhrozek.fedorapeople.org/sssd/1.11.6/man/sssd-ldap.5.html
>
> We may not have "very complex nestings", but complex for sure. And
> complexity is growing. My hope was that it would speed up the logon process.
>
>> In general, neither subdomains_provider nor the matching rules have
>> anything to do with SSH keys whatsoever.
>>
>
> Thank you for confirming my thoughts. Are there any special cases? We don't
> have any subdomains but many forest trust. These are enumerated and marked
> as subdomains even though SSSD does not support forest trusts. I was hoping
> that disabling this setting would make SSSD neglect the trusted forests.
> According to the logs it seems so.
>
>>> But logging on immediatly again we are asked for public
>>> key verification.
>>
>> You're asked for verification of /user/ keys?
>>
>
> We are asked for the password of the public key to unlock the private key.
>
>>>
>>> Red Hat release 7.1/sssd 1.12.2. . Adding
>>>
>>> subdomains_provider = none
>>>
>>> alone ends in not being able to get the public key but are asked for our AD
>>> user accounts password.
>>> Adding
>>>
>>> ldap_groups_use_matching_rule_in_chain = True
>>> ldap_initgroups_use_matching_rule_in_chain = True
>>>
>>> gives the same result. AD user accounts password only. But not the extended
>>> logon time.
>>>
>>> How come?
>>
>> You didn't paste any logs or configuration, so it's hard to tell. But
>> you should first make sure the backend is configured to point to your
>> pubkey attribute with ldap_user_ssh_public_key, then see if sshd is
>> contacting the ssh responder and if the ssh responder is retrieving the
>> keys from cache.
>>
>
> Sorry.
>
> sssd.conf:
> [sssd]
> debug_level = 0 # Levels = 0-9
> config_file_version = 2
> domains =
ad.example.org
> services = nss, pac, pam, ssh
>
> [nss]
> debug_level = 6 # Levels = 0-9
> filter_users =
root,bin,daemon,adm,lp,sync,shutdown,halt,mail,uucp,operator,games,gopher,ftp,nobody,dbus,vcsa,abrt,haldaemon,ntp,saslauth,postfix,sshd,tcpdump,puppet
> filter_groups =
root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,mail,uucp,man,games,gopher,video,dip,ftp,lock,audio,nobody,users,dbus,utmp,utempter,floppy,vsca,abrt,cdrom,tape,dialout,haldaemon,ntp,saslauth,postdrop,postfix,sshd,tcpdump,stapusr,stapsys,stapdev,slocate,puppet,wbpriv
> # Comment out if the users have the shell and home dir set on the AD side
> allowed_shells = /etc/shells
> default_shell = /bin/bash
> fallback_homedir = /home/%u
>
> [pac]
> debug_level = 0 # Levels = 0-9
>
> [pam]
> debug_level = 6 # Levels = 0-9
> offline_credentials_expiration = 0 # For ever
>
> [ssh]
> debug_level = 9 # Levels = 0-9
>
> [
domain/ad.example.org]
> debug_level = 6 # Levels = 0-9
> id_provider = ad
> auth_provider = ad
> access_provider = ad
> chpass_provider = ad
>
> subdomains_provider = none
>
> ldap_page_size = 1000
>
> enumerate = False
>
> ldap_id_mapping = False
>
> ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
> ldap_user_ssh_public_key = altSecurityIdentities
> # ldap_groups_use_matching_rule_in_chain = True
> # ldap_initgroups_use_matching_rule_in_chain = True
> ldap_use_tokengroups = True
>
> dyndns_update = False
> dyndns_update_ptr = False
>
> cache_credentials = true
> krb5_store_password_if_offline = true
>
> Using default settings for subdomains_provider, the key is retrieved:
> (Thu Aug 20 20:56:01 2015) [sssd[ssh]] [sss_dp_req_destructor] (0x0400):
> Deleting request: [0x7f78cb8f8490:domains@ad.example.org]
> (Thu Aug 20 20:56:11 2015) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus conn:
> 0x7f78cd092130
> (Thu Aug 20 20:56:11 2015) [sssd[ssh]] [sbus_dispatch] (0x4000):
> Dispatching.
> (Thu Aug 20 20:56:11 2015) [sssd[ssh]] [sbus_message_handler] (0x4000):
> Received SBUS method [ping]
> (Thu Aug 20 20:56:11 2015) [sssd[ssh]] [sbus_get_sender_id_send] (0x2000):
> Not a sysbus message, quit
> (Thu Aug 20 20:56:11 2015) [sssd[ssh]] [sbus_handler_got_caller_id]
> (0x4000): Received SBUS method [ping]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [get_client_cred] (0x4000): Client
> creds: euid[10287217] egid[10000513] pid[18907].
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0x7f78cd09a2f0][18]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [accept_fd_handler] (0x0400): Client
> connected!
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0x7f78cd09a2f0][18]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
> Received client version [0].
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
> Offered version [0].
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0x7f78cd09a2f0][18]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0x7f78cd09a2f0][18]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [ssh_cmd_parse_request] (0x0400):
> Requested domain [<ALL>]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [ssh_cmd_parse_request] (0x0400):
> Parsing name [myLoginID][<ALL>]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sss_parse_name_for_domains]
> (0x0200): name 'myLoginID' matched without domain, user is myLoginID
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sss_ssh_cmd_get_user_pubkeys]
> (0x0400): Requesting SSH user public keys for [myLoginID] from [<ALL>]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sss_dp_issue_request] (0x0400):
> Issuing request for [0x7f78cb8f6c20:1:myLoginID@ad.example.org]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sss_dp_get_account_msg] (0x0400):
> Creating request for [ad.example.org][1][1][name=myLoginID]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sbus_add_timeout] (0x2000):
> 0x7f78cd096fa0
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sss_dp_internal_get_send] (0x0400):
> Entering request [0x7f78cb8f6c20:1:myLoginID@ad.example.org]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sbus_remove_timeout] (0x2000):
> 0x7f78cd096fa0
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus conn:
> 0x7f78cd093900
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sbus_dispatch] (0x4000):
> Dispatching.
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sss_dp_get_reply] (0x1000): Got
> reply from Data Provider - DP error code: 0 errno: 0 error message: Success
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [ssh_user_pubkeys_search_next]
> (0x0400): Requesting SSH user public keys for [myLoginID(a)ad.example.org]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [ldb] (0x4000): Added timed event
> "ltdb_callback": 0x7f78cd09be80
>
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [ldb] (0x4000): Added timed event
> "ltdb_timeout": 0x7f78cd09bfb0
>
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [ldb] (0x4000): Running timer event
> 0x7f78cd09be80 "ltdb_callback"
>
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [ldb] (0x4000): Destroying timer
> event 0x7f78cd09bfb0 "ltdb_timeout"
>
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [ldb] (0x4000): Ending timer event
> 0x7f78cd09be80 "ltdb_callback"
>
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [decode_and_add_base64_data]
> (0x4000): Mssing element, nothing to do.
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [decode_and_add_base64_data]
> (0x4000): Mssing element, nothing to do.
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [sss_dp_req_destructor] (0x0400):
> Deleting request: [0x7f78cb8f6c20:1:myLoginID@ad.example.org]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0x7f78cd09a2f0][18]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0x7f78cd09a2f0][18]
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [client_recv] (0x0200): Client
> disconnected!
> (Thu Aug 20 20:56:18 2015) [sssd[ssh]] [client_destructor] (0x2000):
> Terminated client [0x7f78cd09a2f0][18]
>
> subdomains_provider = none:
> (Thu Aug 20 20:43:20 2015) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus conn:
> 0x7fc01019e130
> (Thu Aug 20 20:43:20 2015) [sssd[ssh]] [sbus_dispatch] (0x4000):
> Dispatching.
> (Thu Aug 20 20:43:20 2015) [sssd[ssh]] [sbus_message_handler] (0x4000):
> Received SBUS method [ping]
> (Thu Aug 20 20:43:20 2015) [sssd[ssh]] [sbus_get_sender_id_send] (0x2000):
> Not a sysbus message, quit
> (Thu Aug 20 20:43:20 2015) [sssd[ssh]] [sbus_handler_got_caller_id]
> (0x4000): Received SBUS method [ping]
> (Thu Aug 20 20:43:30 2015) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus conn:
> 0x7fc01019e130
> (Thu Aug 20 20:43:30 2015) [sssd[ssh]] [sbus_dispatch] (0x4000):
> Dispatching.
> (Thu Aug 20 20:43:30 2015) [sssd[ssh]] [sbus_message_handler] (0x4000):
> Received SBUS method [ping]
> (Thu Aug 20 20:43:30 2015) [sssd[ssh]] [sbus_get_sender_id_send] (0x2000):
> Not a sysbus message, quit
> (Thu Aug 20 20:43:30 2015) [sssd[ssh]] [sbus_handler_got_caller_id]
> (0x4000): Received SBUS method [ping]
>
>
>> btw pubkey integration with AD is not something we test, so there might
>> be dragons..
>
> I'll watch my back...
>
> Regards
> Davor
>
>> _______________________________________________
>> sssd-users mailing list
>> sssd-users(a)lists.fedorahosted.org
>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>>
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users