Hi!
We store our public ssh keys in AD user account (altSecurityIdentities). Red Hat release 6.6/sssd 1.11.6. 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
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. But logging on immediatly again we are asked for public key verification.
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?
Regards Davor vusir
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
~~~~~~~~~~~~~~~ 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?
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?
In general, neither subdomains_provider nor the matching rules have anything to do with SSH keys whatsoever.
But logging on immediatly again we are asked for public key verification.
You're asked for verification of /user/ keys?
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.
btw pubkey integration with AD is not something we test, so there might be dragons..
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 = noneWhy 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 = Truemakes 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 = nonealone 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 = Truegives 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@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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
See https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-i... for some performance tips.
Sorry for being terse.
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."
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@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Jakub Hrozek skrev den 2015-08-20 22:23:
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
It is.
See https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-i... for some performance tips.
Thank you. The tips did make difference.
Sorry for being terse.
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 = noneWhy 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 = Truemakes 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."
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 = nonealone 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 = Truegives 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 = trueUsing 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@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (22/08/15 15:32), Davor Vusir wrote:
Jakub Hrozek skrev den 2015-08-20 22:23:
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
It is.
See https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-i... for some performance tips.
Thank you. The tips did make difference.
Sorry for being terse.
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.
In previous mail, you provided log files from ssh responder, which just tried to look up cached ssh key in sssd cache But we would need to see a different log file to confirm whether public ssh key was retrieved from LDAP/AD.
Please: * clear old log files and sssd cache * increase debug_level in domain section to 9 * restart sssd * call "getent passwd user_with_ssh_key_in_ad" * provide log files from domain section.
[sssd] debug_level = 0 # Levels = 0-9
BTW in this case it's not a big problem; but in other options it can cause headaches while troubleshooting.
The part after character "#" is not considered as a comment. The comment have to start this character "#" at the begining of line.
LS
Lukas Slebodnik skrev den 2015-08-25 11:51:
On (22/08/15 15:32), Davor Vusir wrote:
Jakub Hrozek skrev den 2015-08-20 22:23:
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
It is.
See https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-i... for some performance tips.
Thank you. The tips did make difference.
Sorry for being terse.
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.
In previous mail, you provided log files from ssh responder, which just tried to look up cached ssh key in sssd cache But we would need to see a different log file to confirm whether public ssh key was retrieved from LDAP/AD.
Please:
- clear old log files and sssd cache
rm /var/log/sssd/sssd_ad.example.org
- increase debug_level in domain section to 9
- restart sssd
service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start
- call "getent passwd user_with_ssh_key_in_ad"
myloginid:*:10051785:10000513:Davor Vusir:/home/myloginid:/bin/bash
- provide log files from domain section.
I guess that this is the part you are interested in: (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_get_primary_name] (0x0400): Processing object myLoginID (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Processing user myLoginID (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x2000): Adding originalDN [CN=Davor Vusir,OU=Admins,OU=CT,DC=ad,DC=example,DC=org] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20150817101423.0Z] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Adding user principal [myLoginID@AD.EXAMPLE.ORG] to attributes of [myLoginID]. ... (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding sshPublicKey [c3NoLXJzYSBaPUFaRjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): authType is not available for [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding altSecurityIdentities [c3NoLXJzYSBStUFStjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will add lowercased aliases (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Storing info for user myLoginID
[sssd] debug_level = 0 # Levels = 0-9
BTW in this case it's not a big problem; but in other options it can cause headaches while troubleshooting.
The part after character "#" is not considered as a comment. The comment have to start this character "#" at the begining of line.
I see. Thank you for mentioning it. Removed now.
Regards Davor
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (25/08/15 19:35), Davor Vusir wrote:
Lukas Slebodnik skrev den 2015-08-25 11:51:
On (22/08/15 15:32), Davor Vusir wrote:
Jakub Hrozek skrev den 2015-08-20 22:23:
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
It is.
See https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-i... for some performance tips.
Thank you. The tips did make difference.
Sorry for being terse.
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.
In previous mail, you provided log files from ssh responder, which just tried to look up cached ssh key in sssd cache But we would need to see a different log file to confirm whether public ssh key was retrieved from LDAP/AD.
Please:
- clear old log files and sssd cache
rm /var/log/sssd/sssd_ad.example.org
- increase debug_level in domain section to 9
- restart sssd
service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start
- call "getent passwd user_with_ssh_key_in_ad"
myloginid:*:10051785:10000513:Davor Vusir:/home/myloginid:/bin/bash
- provide log files from domain section.
I guess that this is the part you are interested in:
exactly :-)
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_get_primary_name] (0x0400): Processing object myLoginID (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Processing user myLoginID (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x2000): Adding originalDN [CN=Davor Vusir,OU=Admins,OU=CT,DC=ad,DC=example,DC=org] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20150817101423.0Z] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Adding user principal [myLoginID@AD.EXAMPLE.ORG] to attributes of [myLoginID]. ... (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding sshPublicKey [c3NoLXJzYSBaPUFaRjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=] to attributes of [myLoginID].
Ok, the correct ldapt attribute is stored as ssh public key into sssd cache for that user.
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): authType is not available for [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding altSecurityIdentities [c3NoLXJzYSBStUFStjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=] to attributes of [myLoginID].
This one is casued by following option ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
And should not have any effect to ssh <-> sssd integration.
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will add lowercased aliases (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Storing info for user myLoginID
Now you can test with command line utility sss_ssh_authorizedkeys wheter ssh responder is correctly configured. ("ssh" should be listed in option services; in sssd section)
If the public key is returned then you need to check sshd configuration files for proper integration.
@see more details in man sss_ssh_authorizedkeys
LS
On 2015-08-25 20:25, Lukas Slebodnik wrote:
On (25/08/15 19:35), Davor Vusir wrote:
Lukas Slebodnik skrev den 2015-08-25 11:51:
On (22/08/15 15:32), Davor Vusir wrote:
Jakub Hrozek skrev den 2015-08-20 22:23:
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
It is.
See https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-i... for some performance tips.
Thank you. The tips did make difference.
Sorry for being terse.
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.
In previous mail, you provided log files from ssh responder, which just tried to look up cached ssh key in sssd cache But we would need to see a different log file to confirm whether public ssh key was retrieved from LDAP/AD.
Please:
- clear old log files and sssd cache
rm /var/log/sssd/sssd_ad.example.org
- increase debug_level in domain section to 9
- restart sssd
service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start
- call "getent passwd user_with_ssh_key_in_ad"
myloginid:*:10051785:10000513:Davor Vusir:/home/myloginid:/bin/bash
- provide log files from domain section.
I guess that this is the part you are interested in:
exactly :-)
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_get_primary_name] (0x0400): Processing object myLoginID (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Processing user myLoginID (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x2000): Adding originalDN [CN=Davor Vusir,OU=Admins,OU=CT,DC=ad,DC=example,DC=org] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20150817101423.0Z] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Adding user principal [myLoginID@AD.EXAMPLE.ORG] to attributes of [myLoginID]. ... (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding sshPublicKey [c3NoLXJzYSBaPUFaRjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=] to attributes of [myLoginID].
Ok, the correct ldapt attribute is stored as ssh public key into sssd cache for that user.
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): authType is not available for [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding altSecurityIdentities [c3NoLXJzYSBStUFStjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=] to attributes of [myLoginID].
This one is casued by following option ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
And should not have any effect to ssh <-> sssd integration.
I realized that while going through the log. The attribute is unnecesseraly cached . Will remove.
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will add lowercased aliases (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Storing info for user myLoginID
Now you can test with command line utility sss_ssh_authorizedkeys wheter ssh responder is correctly configured. ("ssh" should be listed in option services; in sssd section) If the public key is returned then you need to check sshd configuration files for proper integration.
@see more details in man sss_ssh_authorizedkeys
[root@client-1 ~]# sss_ssh_authorizedkeys myLoginID ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
[myLoginID@client-1 ~]# sss_ssh_authorizedkeys myLoginID ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
Seems to work. But as soon as I put "subdomains_provider = none" either sshd or sssd (I believe it's sssd) bypasses the ssh public key check. It recognizes that it should check for the password to unlock the private key, but doesn't care what I'm typing. It solely check for the kerberos password.
As soon as I comment out "subdomains_provider = none" user accounts with public key uses this type of authentication only and user accounts with Kerberos password uses Kerberos authentication only. Which, of course, is the goal.
I don't expect you to comment on the sshd_config but here are relevant parts of both sshd_config and sssd.conf. Both "ct-linuxuberadmins" and "ct-linuxservicesadmins" in sshd_config are AD-groups with corresponding sudoers-files.
sssd.conf: [domain/ad.example.org] debug_level = 6 id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad
subdomains_provider = none # subdomain_enumerate = none ignore_group_members = True
enumerate = False
ldap_page_size = 1000 ldap_id_mapping = False ldap_purge_cache_timeout = 0 ldap_user_ssh_public_key = altSecurityIdentities ldap_use_tokengroups = True
dyndns_update = False dyndns_update_ptr = False
cache_credentials = true krb5_store_password_if_offline = true
sshd_config: PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication yes
UsePAM yes
Match Group ct-linuxuberadmins AuthorizedKeysCommand /bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser svcCTSSHDbind
Match Group ct-linuxservicesadmins PubkeyAuthentication no
Regards Davor
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (26/08/15 13:09), Davor Vusir wrote:
On 2015-08-25 20:25, Lukas Slebodnik wrote:
On (25/08/15 19:35), Davor Vusir wrote:
Lukas Slebodnik skrev den 2015-08-25 11:51:
On (22/08/15 15:32), Davor Vusir wrote:
Jakub Hrozek skrev den 2015-08-20 22:23:
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
It is.
See https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-i... for some performance tips.
Thank you. The tips did make difference.
Sorry for being terse.
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.
In previous mail, you provided log files from ssh responder, which just tried to look up cached ssh key in sssd cache But we would need to see a different log file to confirm whether public ssh key was retrieved from LDAP/AD.
Please:
- clear old log files and sssd cache
rm /var/log/sssd/sssd_ad.example.org
- increase debug_level in domain section to 9
- restart sssd
service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start
- call "getent passwd user_with_ssh_key_in_ad"
myloginid:*:10051785:10000513:Davor Vusir:/home/myloginid:/bin/bash
- provide log files from domain section.
I guess that this is the part you are interested in:
exactly :-)
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_get_primary_name] (0x0400): Processing object myLoginID (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Processing user myLoginID (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x2000): Adding originalDN [CN=Davor Vusir,OU=Admins,OU=CT,DC=ad,DC=example,DC=org] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20150817101423.0Z] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Adding user principal [myLoginID@AD.EXAMPLE.ORG] to attributes of [myLoginID]. ... (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding sshPublicKey [c3NoLXJzYSBaPUFaRjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=] to attributes of [myLoginID].
Ok, the correct ldapt attribute is stored as ssh public key into sssd cache for that user.
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): authType is not available for [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding altSecurityIdentities [c3NoLXJzYSBStUFStjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=] to attributes of [myLoginID].
This one is casued by following option ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
And should not have any effect to ssh <-> sssd integration.
I realized that while going through the log. The attribute is unnecesseraly cached . Will remove.
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will add lowercased aliases (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Storing info for user myLoginID
Now you can test with command line utility sss_ssh_authorizedkeys wheter ssh responder is correctly configured. ("ssh" should be listed in option services; in sssd section) If the public key is returned then you need to check sshd configuration files for proper integration.
@see more details in man sss_ssh_authorizedkeys
[root@client-1 ~]# sss_ssh_authorizedkeys myLoginID ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
[myLoginID@client-1 ~]# sss_ssh_authorizedkeys myLoginID ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
Seems to work. But as soon as I put "subdomains_provider = none" either sshd or sssd (I believe it's sssd) bypasses the ssh public key check. It recognizes that it should check for the password to unlock the private key, but doesn't care what I'm typing. It solely check for the kerberos password.
Does sss_ssh_authorizedkeys returns public key with "subdomains_provider = none"? Please try with empty cache.
As soon as I comment out "subdomains_provider = none" user accounts with public key uses this type of authentication only and user accounts with Kerberos password uses Kerberos authentication only. Which, of course, is the goal.
I don't expect you to comment on the sshd_config but here are relevant parts of both sshd_config and sssd.conf. Both "ct-linuxuberadmins" and "ct-linuxservicesadmins" in sshd_config are AD-groups with corresponding sudoers-files.
sssd.conf: [domain/ad.example.org] debug_level = 6 id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad
subdomains_provider = none # subdomain_enumerate = none ignore_group_members = True
enumerate = False
ldap_page_size = 1000 ldap_id_mapping = False ldap_purge_cache_timeout = 0 ldap_user_ssh_public_key = altSecurityIdentities ldap_use_tokengroups = True
dyndns_update = False dyndns_update_ptr = False
cache_credentials = true krb5_store_password_if_offline = true
sshd_config: PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication yes
UsePAM yes
Match Group ct-linuxuberadmins AuthorizedKeysCommand /bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser svcCTSSHDbind
Match Group ct-linuxservicesadmins PubkeyAuthentication no
Maybe I'm wrong but you might miss some groups with disabled subdomain_provider. Please try with empty cache
So sshd will not get to the section with AuthorizedKeysCommand.
LS
On 2015-08-26 21:36, Lukas Slebodnik wrote:
On (26/08/15 13:09), Davor Vusir wrote:
On 2015-08-25 20:25, Lukas Slebodnik wrote:
On (25/08/15 19:35), Davor Vusir wrote:
Lukas Slebodnik skrev den 2015-08-25 11:51:
On (22/08/15 15:32), Davor Vusir wrote:
Jakub Hrozek skrev den 2015-08-20 22:23: > 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 > It is.
> See > https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-i... > for some performance tips. > Thank you. The tips did make difference.
> Sorry for being terse. > 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.
In previous mail, you provided log files from ssh responder, which just tried to look up cached ssh key in sssd cache But we would need to see a different log file to confirm whether public ssh key was retrieved from LDAP/AD.
Please:
- clear old log files and sssd cache
rm /var/log/sssd/sssd_ad.example.org
- increase debug_level in domain section to 9
- restart sssd
service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start
- call "getent passwd user_with_ssh_key_in_ad"
myloginid:*:10051785:10000513:Davor Vusir:/home/myloginid:/bin/bash
- provide log files from domain section.
I guess that this is the part you are interested in:
exactly :-)
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_get_primary_name] (0x0400): Processing object myLoginID (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Processing user myLoginID (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x2000): Adding originalDN [CN=Davor Vusir,OU=Admins,OU=CT,DC=ad,DC=example,DC=org] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20150817101423.0Z] to attributes of [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Adding user principal [myLoginID@AD.EXAMPLE.ORG] to attributes of [myLoginID]. ... (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding sshPublicKey [c3NoLXJzYSBaPUFaRjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=] to attributes of [myLoginID].
Ok, the correct ldapt attribute is stored as ssh public key into sssd cache for that user.
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): authType is not available for [myLoginID]. (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding altSecurityIdentities [c3NoLXJzYSBStUFStjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=] to attributes of [myLoginID].
This one is casued by following option ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
And should not have any effect to ssh <-> sssd integration.
I realized that while going through the log. The attribute is unnecesseraly cached . Will remove.
(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will add lowercased aliases (Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user] (0x0400): Storing info for user myLoginID
Now you can test with command line utility sss_ssh_authorizedkeys wheter ssh responder is correctly configured. ("ssh" should be listed in option services; in sssd section) If the public key is returned then you need to check sshd configuration files for proper integration.
@see more details in man sss_ssh_authorizedkeys
[root@client-1 ~]# sss_ssh_authorizedkeys myLoginID ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
[myLoginID@client-1 ~]# sss_ssh_authorizedkeys myLoginID ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
Seems to work. But as soon as I put "subdomains_provider = none" either sshd or sssd (I believe it's sssd) bypasses the ssh public key check. It recognizes that it should check for the password to unlock the private key, but doesn't care what I'm typing. It solely check for the kerberos password.
Does sss_ssh_authorizedkeys returns public key with "subdomains_provider = none"? Please try with empty cache.
Is this the correct procedure? 1. Logged in as "nonPublicKeyUser" su-ing to root in one terminal: [root@server-1 ~]# service sssd stop Redirecting to /bin/systemctl stop sssd.service [root@server-1 ~]# rm -f /var/log/sssd/sssd* [root@server-1 ~]# vi /etc/sssd/sssd.conf [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]#
2. In another terminal from client-1: PublicKeyUser@server-1 ~ $ ssh server-1.subdomain.example.org Enter passphrase for key '/home/PublicKeyUser/.ssh/id_rsa': <- No password given. Just pressed <return>. Password: Last login: Wed Aug 26 12:56:21 2015 from client-1.subdomain2.example.org [PublicKeyUser@server-1 ~]$ sss_ssh_authorizedkeys PublicKeyUser ssh-rsa AAAAB3NzaC1yc2EAAA... [PublicKeyUser@server-1 ~]$ exit
3. Back to the first terminal: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# sss_ssh_authorizedkeys PublicKeyUser ssh-rsa AAAAB3NzaC1yc2E... [root@server-1 ~]#
As soon as I comment out "subdomains_provider = none" user accounts with public key uses this type of authentication only and user accounts with Kerberos password uses Kerberos authentication only. Which, of course, is the goal.
I don't expect you to comment on the sshd_config but here are relevant parts of both sshd_config and sssd.conf. Both "ct-linuxuberadmins" and "ct-linuxservicesadmins" in sshd_config are AD-groups with corresponding sudoers-files.
sssd.conf: [domain/ad.example.org] debug_level = 6 id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad
subdomains_provider = none # subdomain_enumerate = none ignore_group_members = True
enumerate = False
ldap_page_size = 1000 ldap_id_mapping = False ldap_purge_cache_timeout = 0 ldap_user_ssh_public_key = altSecurityIdentities ldap_use_tokengroups = True
dyndns_update = False dyndns_update_ptr = False
cache_credentials = true krb5_store_password_if_offline = true
sshd_config: PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication yes
UsePAM yes
Match Group ct-linuxuberadmins AuthorizedKeysCommand /bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser svcCTSSHDbind
Match Group ct-linuxservicesadmins PubkeyAuthentication no
Maybe I'm wrong but you might miss some groups with disabled subdomain_provider. Please try with empty cache
So sshd will not get to the section with AuthorizedKeysCommand.
After step 3 above: [root@server-1 ~]# getent group ct-linuxuberadmins ct-linuxuberadmins:*:10287220: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# getent group ct-linuxservicesadmins uuct-gg-linuxservicesadmins:*:10287637: [root@server-1 ~]#
Regards Davor
LS
On (27/08/15 08:21), Davor Vusir wrote:
On 2015-08-26 21:36, Lukas Slebodnik wrote:
On (26/08/15 13:09), Davor Vusir wrote:
On 2015-08-25 20:25, Lukas Slebodnik wrote:
Now you can test with command line utility sss_ssh_authorizedkeys wheter ssh responder is correctly configured. ("ssh" should be listed in option services; in sssd section) If the public key is returned then you need to check sshd configuration files for proper integration.
@see more details in man sss_ssh_authorizedkeys
[root@client-1 ~]# sss_ssh_authorizedkeys myLoginID ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
[myLoginID@client-1 ~]# sss_ssh_authorizedkeys myLoginID ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
Seems to work. But as soon as I put "subdomains_provider = none" either sshd or sssd (I believe it's sssd) bypasses the ssh public key check. It recognizes that it should check for the password to unlock the private key, but doesn't care what I'm typing. It solely check for the kerberos password.
Does sss_ssh_authorizedkeys returns public key with "subdomains_provider = none"? Please try with empty cache.
Is this the correct procedure?
yes.
Logged in as "nonPublicKeyUser" su-ing to root in one terminal: [root@server-1 ~]# service sssd stop Redirecting to /bin/systemctl stop sssd.service [root@server-1 ~]# rm -f /var/log/sssd/sssd* [root@server-1 ~]# vi /etc/sssd/sssd.conf [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]#
In another terminal from client-1: PublicKeyUser@server-1 ~ $ ssh server-1.subdomain.example.org Enter passphrase for key '/home/PublicKeyUser/.ssh/id_rsa': <- No password given. Just pressed <return>. Password: Last login: Wed Aug 26 12:56:21 2015 from client-1.subdomain2.example.org [PublicKeyUser@server-1 ~]$ sss_ssh_authorizedkeys PublicKeyUser ssh-rsa AAAAB3NzaC1yc2EAAA... [PublicKeyUser@server-1 ~]$ exit
Back to the first terminal: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# sss_ssh_authorizedkeys PublicKeyUser ssh-rsa AAAAB3NzaC1yc2E... [root@server-1 ~]#
You could immediatelly run as root "sss_ssh_authorizedkeys PublicKeyUser" after restarting sssd with new configuration.
But it looks like public key is returned even with disabled subdomain provider.
As soon as I comment out "subdomains_provider = none" user accounts with public key uses this type of authentication only and user accounts with Kerberos password uses Kerberos authentication only. Which, of course, is the goal.
I don't expect you to comment on the sshd_config but here are relevant parts of both sshd_config and sssd.conf. Both "ct-linuxuberadmins" and "ct-linuxservicesadmins" in sshd_config are AD-groups with corresponding sudoers-files.
sssd.conf: [domain/ad.example.org] debug_level = 6 id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad
subdomains_provider = none # subdomain_enumerate = none ignore_group_members = True
enumerate = False
ldap_page_size = 1000 ldap_id_mapping = False ldap_purge_cache_timeout = 0 ldap_user_ssh_public_key = altSecurityIdentities ldap_use_tokengroups = True
dyndns_update = False dyndns_update_ptr = False
cache_credentials = true krb5_store_password_if_offline = true
sshd_config: PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication yes
UsePAM yes
Match Group ct-linuxuberadmins AuthorizedKeysCommand /bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser svcCTSSHDbind
Match Group ct-linuxservicesadmins PubkeyAuthentication no
Maybe I'm wrong but you might miss some groups with disabled subdomain_provider. Please try with empty cache
So sshd will not get to the section with AuthorizedKeysCommand.
After step 3 above: [root@server-1 ~]# getent group ct-linuxuberadmins ct-linuxuberadmins:*:10287220: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# getent group ct-linuxservicesadmins uuct-gg-linuxservicesadmins:*:10287637:
users are not listed due to enabeld option ignore_group_members.
I would be more interested in output of command. "id PublicKeyUser" with enabled and disabled subdomain provider.
LS
On 2015-08-27 08:39, Lukas Slebodnik wrote:
On (27/08/15 08:21), Davor Vusir wrote:
On 2015-08-26 21:36, Lukas Slebodnik wrote:
On (26/08/15 13:09), Davor Vusir wrote:
On 2015-08-25 20:25, Lukas Slebodnik wrote:
Now you can test with command line utility sss_ssh_authorizedkeys wheter ssh responder is correctly configured. ("ssh" should be listed in option services; in sssd section) If the public key is returned then you need to check sshd configuration files for proper integration.
@see more details in man sss_ssh_authorizedkeys
[root@client-1 ~]# sss_ssh_authorizedkeys myLoginID ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
[myLoginID@client-1 ~]# sss_ssh_authorizedkeys myLoginID ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
Seems to work. But as soon as I put "subdomains_provider = none" either sshd or sssd (I believe it's sssd) bypasses the ssh public key check. It recognizes that it should check for the password to unlock the private key, but doesn't care what I'm typing. It solely check for the kerberos password.
Does sss_ssh_authorizedkeys returns public key with "subdomains_provider = none"? Please try with empty cache.
Is this the correct procedure?
yes.
Logged in as "nonPublicKeyUser" su-ing to root in one terminal: [root@server-1 ~]# service sssd stop Redirecting to /bin/systemctl stop sssd.service [root@server-1 ~]# rm -f /var/log/sssd/sssd* [root@server-1 ~]# vi /etc/sssd/sssd.conf [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]#
In another terminal from client-1: PublicKeyUser@server-1 ~ $ ssh server-1.subdomain.example.org Enter passphrase for key '/home/PublicKeyUser/.ssh/id_rsa': <- No password given. Just pressed <return>. Password: Last login: Wed Aug 26 12:56:21 2015 from client-1.subdomain2.example.org [PublicKeyUser@server-1 ~]$ sss_ssh_authorizedkeys PublicKeyUser ssh-rsa AAAAB3NzaC1yc2EAAA... [PublicKeyUser@server-1 ~]$ exit
Back to the first terminal: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# sss_ssh_authorizedkeys PublicKeyUser ssh-rsa AAAAB3NzaC1yc2E... [root@server-1 ~]#
You could immediatelly run as root "sss_ssh_authorizedkeys PublicKeyUser" after restarting sssd with new configuration.
Same result as before.
But it looks like public key is returned even with disabled subdomain provider.
As soon as I comment out "subdomains_provider = none" user accounts with public key uses this type of authentication only and user accounts with Kerberos password uses Kerberos authentication only. Which, of course, is the goal.
I don't expect you to comment on the sshd_config but here are relevant parts of both sshd_config and sssd.conf. Both "ct-linuxuberadmins" and "ct-linuxservicesadmins" in sshd_config are AD-groups with corresponding sudoers-files.
sssd.conf: [domain/ad.example.org] debug_level = 6 id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad
subdomains_provider = none # subdomain_enumerate = none ignore_group_members = True
enumerate = False
ldap_page_size = 1000 ldap_id_mapping = False ldap_purge_cache_timeout = 0 ldap_user_ssh_public_key = altSecurityIdentities ldap_use_tokengroups = True
dyndns_update = False dyndns_update_ptr = False
cache_credentials = true krb5_store_password_if_offline = true
sshd_config: PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication yes
UsePAM yes
Match Group ct-linuxuberadmins AuthorizedKeysCommand /bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser svcCTSSHDbind
Match Group ct-linuxservicesadmins PubkeyAuthentication no
Maybe I'm wrong but you might miss some groups with disabled subdomain_provider. Please try with empty cache
So sshd will not get to the section with AuthorizedKeysCommand.
After step 3 above: [root@server-1 ~]# getent group ct-linuxuberadmins ct-linuxuberadmins:*:10287220: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# getent group ct-linuxservicesadmins uuct-gg-linuxservicesadmins:*:10287637:
users are not listed due to enabeld option ignore_group_members.
I would be more interested in output of command. "id PublicKeyUser" with enabled and disabled subdomain provider.
"subdomains_provider = none": [root@server-1 ~]# id PublicKeyUser uid=10051785(PublicKeyUser) gid=10000513(domain users) groups=10000513(domain users) [root@its-srv001-t ~]#
"#subdomains_provider = none": uid=10051785(PublicKeyUser) gid=10000513(domain users) groups=10000513(domain users),10257368(ct-lg-admins),... all other groups...
Regards Davor
LS
On (27/08/15 12:29), Davor Vusir wrote:
On 2015-08-27 08:39, Lukas Slebodnik wrote:
On (27/08/15 08:21), Davor Vusir wrote:
Back to the first terminal: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# sss_ssh_authorizedkeys PublicKeyUser ssh-rsa AAAAB3NzaC1yc2E... [root@server-1 ~]#
You could immediatelly run as root "sss_ssh_authorizedkeys PublicKeyUser" after restarting sssd with new configuration.
Same result as before.
OK, so the problem is not with public ssh key :-)
[root@server-1 ~]# getent group ct-linuxuberadmins ct-linuxuberadmins:*:10287220: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# getent group ct-linuxservicesadmins uuct-gg-linuxservicesadmins:*:10287637:
users are not listed due to enabeld option ignore_group_members.
I would be more interested in output of command. "id PublicKeyUser" with enabled and disabled subdomain provider.
"subdomains_provider = none": [root@server-1 ~]# id PublicKeyUser uid=10051785(PublicKeyUser) gid=10000513(domain users) groups=10000513(domain users) [root@its-srv001-t ~]#
"#subdomains_provider = none": uid=10051785(PublicKeyUser) gid=10000513(domain users) groups=10000513(domain users),10257368(ct-lg-admins),... all other groups...
So here is a problem. User does not have all groups with disabled subdomain provider. If you disable subdmain provider then you also disable autodiscovery of domain sids. So it might cause missing groups.
Are all user's groups from the same domain?
You can try to configure default dommain with options: man sssd-ldap -> ldap_idmap_default_domain_sid -> ldap_idmap_default_domain
BTW there is was a bug https://fedorahosted.org/sssd/ticket/2635 which prevents using ldap_idmap_default_domain_sid with disabled subdomain. The bug is fixed in rhel6.7, but not in rhel7.1
LS
On 2015-08-27 14:40, Lukas Slebodnik wrote:
On (27/08/15 12:29), Davor Vusir wrote:
On 2015-08-27 08:39, Lukas Slebodnik wrote:
On (27/08/15 08:21), Davor Vusir wrote:
Back to the first terminal: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# sss_ssh_authorizedkeys PublicKeyUser ssh-rsa AAAAB3NzaC1yc2E... [root@server-1 ~]#
You could immediatelly run as root "sss_ssh_authorizedkeys PublicKeyUser" after restarting sssd with new configuration.
Same result as before.
OK, so the problem is not with public ssh key :-)
[root@server-1 ~]# getent group ct-linuxuberadmins ct-linuxuberadmins:*:10287220: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# getent group ct-linuxservicesadmins uuct-gg-linuxservicesadmins:*:10287637:
users are not listed due to enabeld option ignore_group_members.
I would be more interested in output of command. "id PublicKeyUser" with enabled and disabled subdomain provider.
"subdomains_provider = none": [root@server-1 ~]# id PublicKeyUser uid=10051785(PublicKeyUser) gid=10000513(domain users) groups=10000513(domain users) [root@its-srv001-t ~]#
"#subdomains_provider = none": uid=10051785(PublicKeyUser) gid=10000513(domain users) groups=10000513(domain users),10257368(ct-lg-admins),... all other groups...
So here is a problem. User does not have all groups with disabled subdomain provider. If you disable subdmain provider then you also disable autodiscovery of domain sids. So it might cause missing groups.
I see.
Are all user's groups from the same domain?
All users and groups are from the same domain. No subdomains but forest trusts.
You can try to configure default dommain with options: man sssd-ldap -> ldap_idmap_default_domain_sid -> ldap_idmap_default_domain
BTW there is was a bug https://fedorahosted.org/sssd/ticket/2635 which prevents using ldap_idmap_default_domain_sid with disabled subdomain. The bug is fixed in rhel6.7, but not in rhel7.1
Setting these solved it. Thank you. And I'll bear it in mind for 7.1. Strange though that these settings are needed when all user accounts and groups have got uidnumber and gidnumber assigned.
man sss-ad could be clearer on that the domains NetBIOS name is to be used for ldap_idmap_default_domain.
But I'm still somewhat confused that SSSD treats trusted forests as subdomains. Maybe it's because SSSD doesn't care whether it's a forest trust or not (a trust is trust, so to speak) and lacks the functionality to distinguish the two and therefore adds them as subdomains. Maybe I have to configure [capaths] in krb5.conf.
I'm grateful for your time and guidance, Lukas. It has certainly helped me to understand SSSD more deeply. And thank you for a good product.
Have a nice weekend Davor
LS
On (28/08/15 13:49), Davor Vusir wrote:
On 2015-08-27 14:40, Lukas Slebodnik wrote:
On (27/08/15 12:29), Davor Vusir wrote:
On 2015-08-27 08:39, Lukas Slebodnik wrote:
On (27/08/15 08:21), Davor Vusir wrote:
Back to the first terminal: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# sss_ssh_authorizedkeys PublicKeyUser ssh-rsa AAAAB3NzaC1yc2E... [root@server-1 ~]#
You could immediatelly run as root "sss_ssh_authorizedkeys PublicKeyUser" after restarting sssd with new configuration.
Same result as before.
OK, so the problem is not with public ssh key :-)
[root@server-1 ~]# getent group ct-linuxuberadmins ct-linuxuberadmins:*:10287220: [root@server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf /var/lib/sss/mc/* && service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@server-1 ~]# getent group ct-linuxservicesadmins uuct-gg-linuxservicesadmins:*:10287637:
users are not listed due to enabeld option ignore_group_members.
I would be more interested in output of command. "id PublicKeyUser" with enabled and disabled subdomain provider.
"subdomains_provider = none": [root@server-1 ~]# id PublicKeyUser uid=10051785(PublicKeyUser) gid=10000513(domain users) groups=10000513(domain users) [root@its-srv001-t ~]#
"#subdomains_provider = none": uid=10051785(PublicKeyUser) gid=10000513(domain users) groups=10000513(domain users),10257368(ct-lg-admins),... all other groups...
So here is a problem. User does not have all groups with disabled subdomain provider. If you disable subdmain provider then you also disable autodiscovery of domain sids. So it might cause missing groups.
I see.
Are all user's groups from the same domain?
All users and groups are from the same domain. No subdomains but forest trusts.
You can try to configure default dommain with options: man sssd-ldap -> ldap_idmap_default_domain_sid -> ldap_idmap_default_domain
BTW there is was a bug https://fedorahosted.org/sssd/ticket/2635 which prevents using ldap_idmap_default_domain_sid with disabled subdomain. The bug is fixed in rhel6.7, but not in rhel7.1
Setting these solved it. Thank you. And I'll bear it in mind for 7.1. Strange though that these settings are needed when all user accounts and groups have got uidnumber and gidnumber assigned.
If id mapping is enabled then attributes uidnumber and gidnumber are ignored and UID and GID is generated from SID.
Details man sssd-ldap -> ID MAPPING (-> Mapping Algorithm)
man sss-ad could be clearer on that the domains NetBIOS name is to be used for ldap_idmap_default_domain.
But I'm still somewhat confused that SSSD treats trusted forests as subdomains. Maybe it's because SSSD doesn't care whether it's a forest trust or not (a trust is trust, so to speak) and lacks the functionality to distinguish the two and therefore adds them as subdomains. Maybe I have to configure [capaths] in krb5.conf.
I'm grateful for your time and guidance, Lukas. It has certainly helped me to understand SSSD more deeply. And thank you for a good product.
I'm glad I could help at least with something.
Feel free to file upstream tickets https://fedorahosted.org/sssd/newticket
So we can improve documentation or missing descriptions. You can also propose something in ticket because we know many internal details and something can be obvious for us.
Maybe someone else co
LS
sssd-users@lists.fedorahosted.org
-
Davor Vusir -
Jakub Hrozek -
Lukas Slebodnik