Hi Everyone,
I have an AD domain joined system using realmd and that is working fine. I want to use Group Policy to configure access, and have it set up. I added my users to the Allow log on through Terminal Services GPO and I can successfully authenticate and SSH into the system using kerberos and password auth.
My next problem is SUDO rights - I don't have any. Supposedly, ad_gpo_map_permit is a list of PAM services that are ALWAYS allowed when using GPO access, and this by default includes sudo and sudo-i. Yet I can't SUDO.
In /etc/nsswitch.conf I added:
sudoers: files sss
In /etc/sssd.conf I updated:
services = nss, pam, autofs, sudo
and added the empty [sudo] section.
In the [domain/] section I added: sudo_provider: ad
but from what I've read this isn't needed.
Since I don't want the world to be able to SUDO, I also tried adding to sssd.conf domain section
ad_gpo_map_service = +sudo,+sudo-i
and added my users to the Allow logon as a service GPO, but still no luck.
My sssd sudo log doesn't look like it's querying GPO for permissions through.
(Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_get_rules_send] (0x0400): Running initgroups for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_send] (0x0400): Cache Request [Initgroups by name #2]: New request (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_send] (0x0400): Cache Request [Initgroups by name #2]: Parsing input name [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'mdiorio@internal.ieeeglobalspec.com' matched expression for domain 'internal.ieeeglobalspec.com', user is mdiorio (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_set_name] (0x0400): Cache Request [Initgroups by name #2]: Setting name [mdiorio] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_select_domains] (0x0400): Cache Request [Initgroups by name #2]: Performing a single domain search (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_set_domain] (0x0400): Cache Request [Initgroups by name #2]: Using domain [internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_check_ncache] (0x0400): Cache Request [Initgroups by name #2]: Checking negative cache for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/internal.ieeeglobalspec.com/mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_get_object] (0x0200): Cache Request [Initgroups by name #2]: Requesting info for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_cache_check] (0x0400): Cache Request [Initgroups by name #2]: [mdiorio@internal.ieeeglobalspec.com] entry is valid (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_cache_search] (0x0400): Cache Request [Initgroups by name #2]: Returning info for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_done] (0x0400): Cache Request [Initgroups by name #2]: Finished: Success (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(dataExpireTimestamp<=1485799511)(|(name=defaults)(sudoUser=ALL)(sudoUser=mdiorio@internal.ieeeglobalspec.com)(sudoUser=#1002201109) ...... Truncated AD Group query ---- (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_refresh_rules_send] (0x0400): No expired rules were found for [mdiorio@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com]. (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Retrieving default options for [mdiorio@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(name=defaults))] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 default options for [mdiorio@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): error: [0] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): rules_num: [0] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using protocol version [1] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_get_rules_send] (0x0400): Running initgroups for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_send] (0x0400): Cache Request [Initgroups by name #3]: New request (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_send] (0x0400): Cache Request [Initgroups by name #3]: Parsing input name [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'mdiorio@internal.ieeeglobalspec.com' matched expression for domain 'internal.ieeeglobalspec.com', user is mdiorio (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_set_name] (0x0400): Cache Request [Initgroups by name #3]: Setting name [mdiorio] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_select_domains] (0x0400): Cache Request [Initgroups by name #3]: Performing a single domain search (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_set_domain] (0x0400): Cache Request [Initgroups by name #3]: Using domain [internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_check_ncache] (0x0400): Cache Request [Initgroups by name #3]: Checking negative cache for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/internal.ieeeglobalspec.com/mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_get_object] (0x0200): Cache Request [Initgroups by name #3]: Requesting info for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_cache_check] (0x0400): Cache Request [Initgroups by name #3]: [mdiorio@internal.ieeeglobalspec.com] entry is valid (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_cache_search] (0x0400): Cache Request [Initgroups by name #3]: Returning info for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_done] (0x0400): Cache Request [Initgroups by name #3]: Finished: Success (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(dataExpireTimestamp<=1485799511)(|(name=defaults)(sudoUser=ALL)(sudoUser=mdiorio@internal.ieeeglobalspec.com)(sudoUser=#1002201109) -------------- Truncated group query -------------- (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for [mdiorio@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): error: [0] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): rules_num: [0] (Mon Jan 30 13:05:13 2017) [sssd[sudo]] [client_recv] (0x0200): Client disconnected! (Mon Jan 30 13:05:13 2017) [sssd[sudo]] [client_close_fn] (0x2000): Terminated client [0x7f95cfb03870][20]
One thing I do find strange is that it appears to be trying to find user@domain@domain
Any thoughts - I thought I had this all figured out, but I'm probably missing something simple.
Thanks!
On Mon, Jan 30, 2017 at 06:45:19PM -0000, mdiorio@gmail.com wrote:
Hi Everyone,
I have an AD domain joined system using realmd and that is working fine. I want to use Group Policy to configure access, and have it set up. I added my users to the Allow log on through Terminal Services GPO and I can successfully authenticate and SSH into the system using kerberos and password auth.
My next problem is SUDO rights - I don't have any. Supposedly, ad_gpo_map_permit is a list of PAM services that are ALWAYS allowed when using GPO access, and this by default includes sudo and sudo-i. Yet I can't SUDO.
In /etc/nsswitch.conf I added:
sudoers: files sss
In /etc/sssd.conf I updated:
services = nss, pam, autofs, sudo
This is needed until sssd-1.15 which finally allows the needed services to be socket-activated
and added the empty [sudo] section.
In the [domain/] section I added: sudo_provider: ad
This shouldn't be needed; nor should this be harmful.
but from what I've read this isn't needed.
Since I don't want the world to be able to SUDO, I also tried adding to sssd.conf domain section
ad_gpo_map_service = +sudo,+sudo-i
and added my users to the Allow logon as a service GPO, but still no luck.
My sssd sudo log doesn't look like it's querying GPO for permissions through.
Right, I think you are past the PAM account check (otherwise you wouldn't be able to authenticate to run sudo at all and pam_sss would fail with return code 6), but sudo is not matching any rules.
Are your sudo rules stored in AD or locally in /etc/sudoers? I assume it's in AD, right?
Could you paste one of the rules (feel free to obfuscate the private data..) ?
In general, you should follow https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO to see which part breaks..if sssd does fetch and cache the rules at all, if sssd returns the rules to sudo etc..
(Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_get_rules_send] (0x0400): Running initgroups for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_send] (0x0400): Cache Request [Initgroups by name #2]: New request (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_send] (0x0400): Cache Request [Initgroups by name #2]: Parsing input name [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'mdiorio@internal.ieeeglobalspec.com' matched expression for domain 'internal.ieeeglobalspec.com', user is mdiorio (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_set_name] (0x0400): Cache Request [Initgroups by name #2]: Setting name [mdiorio] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_select_domains] (0x0400): Cache Request [Initgroups by name #2]: Performing a single domain search (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_set_domain] (0x0400): Cache Request [Initgroups by name #2]: Using domain [internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_check_ncache] (0x0400): Cache Request [Initgroups by name #2]: Checking negative cache for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/internal.ieeeglobalspec.com/mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_get_object] (0x0200): Cache Request [Initgroups by name #2]: Requesting info for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_cache_check] (0x0400): Cache Request [Initgroups by name #2]: [mdiorio@internal.ieeeglobalspec.com] entry is valid (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_cache_search] (0x0400): Cache Request [Initgroups by name #2]: Returning info for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_done] (0x0400): Cache Request [Initgroups by name #2]: Finished: Success (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(dataExpireTimestamp<=1485799511)(|(name=defaults)(sudoUser=ALL)(sudoUser=mdiorio@internal.ieeeglobalspec.com)(sudoUser=#1002201109) ...... Truncated AD Group query
(Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_refresh_rules_send] (0x0400): No expired rules were found for [mdiorio@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com]. (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Retrieving default options for [mdiorio@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(name=defaults))] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 default options for [mdiorio@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): error: [0] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): rules_num: [0] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using protocol version [1] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_get_rules_send] (0x0400): Running initgroups for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_send] (0x0400): Cache Request [Initgroups by name #3]: New request (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_send] (0x0400): Cache Request [Initgroups by name #3]: Parsing input name [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'mdiorio@internal.ieeeglobalspec.com' matched expression for domain 'internal.ieeeglobalspec.com', user is mdiorio (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_set_name] (0x0400): Cache Request [Initgroups by name #3]: Setting name [mdiorio] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_select_domains] (0x0400): Cache Request [Initgroups by name #3]: Performing a single domain search (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_set_domain] (0x0400): Cache Request [Initgroups by name #3]: Using domain [internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_check_ncache] (0x0400): Cache Request [Initgroups by name #3]: Checking negative cache for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/internal.ieeeglobalspec.com/mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_get_object] (0x0200): Cache Request [Initgroups by name #3]: Requesting info for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_cache_check] (0x0400): Cache Request [Initgroups by name #3]: [mdiorio@internal.ieeeglobalspec.com] entry is valid (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_cache_search] (0x0400): Cache Request [Initgroups by name #3]: Returning info for [mdiorio@internal.ieeeglobalspec.com] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [cache_req_done] (0x0400): Cache Request [Initgroups by name #3]: Finished: Success (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(dataExpireTimestamp<=1485799511)(|(name=defaults)(sudoUser=ALL)(sudoUser=mdiorio@internal.ieeeglobalspec.com)(sudoUser=#1002201109)
Truncated group query
(Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for [mdiorio@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com]
Yeah, sssd doesn't return any rules, but the domain log should also show if any rules were fetched for the host..
(Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): error: [0] (Mon Jan 30 13:05:11 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): rules_num: [0] (Mon Jan 30 13:05:13 2017) [sssd[sudo]] [client_recv] (0x0200): Client disconnected! (Mon Jan 30 13:05:13 2017) [sssd[sudo]] [client_close_fn] (0x2000): Terminated client [0x7f95cfb03870][20]
One thing I do find strange is that it appears to be trying to find user@domain@domain
This is a minor bug, feel free to open one at https://fedorahosted.org/sssd/newticket, but I'm quite confident it's just a bad debug message, not sssd actually double-qualifying the name..
On Mon, Jan 30, 2017 at 06:45:19PM -0000, mdiorio(a)gmail.com wrote:
Are your sudo rules stored in AD or locally in /etc/sudoers? I assume it's in AD, right?
Seems like this is the part I was missing. Not well explained AT ALL (or anywhere in any documentation I have been looking at)!
I extended AD and am creating the rules now. The one thing that I'm not sure of is: "Non-Unix group support is only available when an appropriate group_plugin is defined in the global defaults sudoRole object."
So if I want to add an AD security group to the rule, how would that be done and is a plugin needed? So I have a security group GS-Technology, I'd enter it as %GS-Technology? What about group with spaces like Domain Admins? Would it be %Domain\ Admins, or do I need to do the domain too? Escaping the ?
%INTERNAL\Domain\ Admins
Documentation is not very firm in this area.
Thanks.
The other thing I'm not quite grasping is the sudoHost option. Can I specify an AD security group that has computer objects as members here? Or must I list each server individually and manually update multiple sudo rules each time a server is domain joined?
On Tue, Jan 31, 2017 at 06:17:01PM -0000, mdiorio@gmail.com wrote:
The other thing I'm not quite grasping is the sudoHost option. Can I specify an AD security group that has computer objects as members here? Or must I list each server individually and manually update multiple sudo rules each time a server is domain joined?
individual hosts or netgroups.
So I created a sudo Rule in AD for full access for domain administrators. I can see that sssd is actually finding and getting the sudo rules. I have tried a few different things for sudoUser but nothing seems to be matching.
cn=fullaccess sudoCommand=ALL sudoHost=ALL sudoUser= Have tried %INTERNAL\Domain\ Admins %Domain Admins@internal %Domain\20Admins@internal
Nothing seems to be matching.
------------------------------- (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Retrieving rules for [a-mdiorio@internal@internal] (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=a-mdiorio@internal)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%Hosting_NetScaler_SuperUsers@internal)(sudoUser=%DB\20GreatPlains\20Admin@internal)(sudoUser=%NetScaler_SuperUsers@internal)(sudoUser=%USE5_SVN_FullAccess@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-9109@oldDomain.net)(sudoUser=%Enterprise\20Admins@internal)(sudoUser=%SQL\20Server\20Admins@internal)(sudoUser=%USE5_NetAppAdmins@internal)(sudoUser=%VI\20Administrators@internal)(sudoUser=%EDCMS_SQL_Admins@internal)(sudoUser=%DSBF_SQL_Admins@internal)(sudoUser=%EDPF_SQL_Admins@internal)(sudoUser=%Data\20Warehouse@internal)(sudoUser=%EDT_SQL_Admins@internal)(sudoUser=%GLS_SQL_Admins@internal)(sudoUser=%Backup\20Access@internal)(sudoUser=%DS_SQL_Admins@internal)(sudoUser=%Domain\20Admins@internal)(sudoUser=%NetApp- Admins@internal)(sudoUser=%NetworkAdmins@internal)(sudoUser=%Schema\20Admins@internal)(sudoUser=%Domain\20Users@internal)(sudoUser=%SCCM_Admins@internal)(sudoUser=%CTX_Admins@internal)(sudoUser=%ESX\20Admins@internal)(sudoUser=%SQL_Admins@internal)(sudoUser=%UCS-Admins@internal)(sudoUser=%ConfigMgr\20Remote\20Control\20Users@internal)(sudoUser=%Denied\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%Backup\20Access@oldDomain.net)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-15027@oldDomain.net)(sudoUser=%SQL\20Server\20Admins@oldDomain.net)(sudoUser=%Data\20Warehouse@oldDomain.net)(sudoUser=%DB\20GreatPlains\20Admin@oldDomain.net)(sudoUser=%Domain\20Users@internal)))] (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_cached_rules_by_user] (0x0400): Replacing sudoUser attribute with sudoUser: #1002201106 (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(sudoUser=+*)(!(|(sudoUser=ALL)(sudoUser=a-mdiorio@internal)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%Hosting_NetScaler_SuperUsers@internal)(sudoUser=%DB\20GreatPlains\20Admin@internal)(sudoUser=%NetScaler_SuperUsers@internal)(sudoUser=%USE5_SVN_FullAccess@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-9109@oldDomain.net)(sudoUser=%Enterprise\20Admins@internal)(sudoUser=%SQL\20Server\20Admins@internal)(sudoUser=%USE5_NetAppAdmins@internal)(sudoUser=%VI\20Administrators@internal)(sudoUser=%EDCMS_SQL_Admins@internal)(sudoUser=%DSBF_SQL_Admins@internal)(sudoUser=%EDPF_SQL_Admins@internal)(sudoUser=%Data\20Warehouse@internal)(sudoUser=%EDT_SQL_Admins@internal)(sudoUser=%GLS_SQL_Admins@internal)(sudoUser=%Backup\20Access@internal)(sudoUser=%DS_SQL_Admins@internal)(sudoUser=%Domain\20Admins@internal)(su doUser=%NetApp-Admins@internal)(sudoUser=%NetworkAdmins@internal)(sudoUser=%Schema\20Admins@internal)(sudoUser=%Domain\20Users@internal)(sudoUser=%SCCM_Admins@internal)(sudoUser=%CTX_Admins@internal)(sudoUser=%ESX\20Admins@internal)(sudoUser=%SQL_Admins@internal)(sudoUser=%UCS-Admins@internal)(sudoUser=%ConfigMgr\20Remote\20Control\20Users@internal)(sudoUser=%Denied\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%Backup\20Access@oldDomain.net)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-15027@oldDomain.net)(sudoUser=%SQL\20Server\20Admins@oldDomain.net)(sudoUser=%Data\20Warehouse@oldDomain.net)(sudoUser=%DB\20GreatPlains\20Admin@oldDomain.net)(sudoUser=%Domain\20Users@internal))))] (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for [a-mdiorio@internal@internal] (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): error: [0] (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): rules_num: [0] (Tue Jan 31 16:52:21 2017) [sssd[sudo]] [client_recv] (0x0200): Client disconnected! (Tue Jan 31 16:52:21 2017) [sssd[sudo]] [client_close_fn] (0x2000): Terminated client [0x7f150b43d090][20]
--------------------------------
On Tue, Jan 31, 2017 at 10:02:04PM -0000, mdiorio@gmail.com wrote:
So I created a sudo Rule in AD for full access for domain administrators. I can see that sssd is actually finding and getting the sudo rules. I have tried a few different things for sudoUser but nothing seems to be matching.
cn=fullaccess sudoCommand=ALL sudoHost=ALL sudoUser= Have tried %INTERNAL\Domain\ Admins %Domain Admins@internal %Domain\20Admins@internal
Nothing seems to be matching.
Please check with ldbsearch how the sudo rules are stored in the cache. I'm not sure about any other way of checking why the query didn't match.
I hope I was not wrong earlier about escaping or that we don't have any bug with escaping spaces, but perhaps can you try with a sudoUser value that doesn't have any space in it to make the test case 'easier' ?
(Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Retrieving rules for [a-mdiorio@internal@internal] (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=a-mdiorio@internal)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%Hosting_NetScaler_SuperUsers@internal)(sudoUser=%DB\20GreatPlains\20Admin@internal)(sudoUser=%NetScaler_SuperUsers@internal)(sudoUser=%USE5_SVN_FullAccess@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-9109@oldDomain.net)(sudoUser=%Enterprise\20Admins@internal)(sudoUser=%SQL\20Server\20Admins@internal)(sudoUser=%USE5_NetAppAdmins@internal)(sudoUser=%VI\20Administrators@internal)(sudoUser=%EDCMS_SQL_Admins@internal)(sudoUser=%DSBF_SQL_Admins@internal)(sudoUser=%EDPF_SQL_Admins@internal)(sudoUser=%Data\20Warehouse@internal)(sudoUser=%EDT_SQL_Admins@internal)(sudoUser=%GLS_SQL_Admins@internal)(sudoUser=%Backup\20Access@internal)(sudoUser=%DS_SQL_Admins@internal)(sudoUser=%Domain\20Admins@internal)(sudoUser=%NetApp- Admins@internal)(sudoUser=%NetworkAdmins@internal)(sudoUser=%Schema\20Admins@internal)(sudoUser=%Domain\20Users@internal)(sudoUser=%SCCM_Admins@internal)(sudoUser=%CTX_Admins@internal)(sudoUser=%ESX\20Admins@internal)(sudoUser=%SQL_Admins@internal)(sudoUser=%UCS-Admins@internal)(sudoUser=%ConfigMgr\20Remote\20Control\20Users@internal)(sudoUser=%Denied\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%Backup\20Access@oldDomain.net)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-15027@oldDomain.net)(sudoUser=%SQL\20Server\20Admins@oldDomain.net)(sudoUser=%Data\20Warehouse@oldDomain.net)(sudoUser=%DB\20GreatPlains\20Admin@oldDomain.net)(sudoUser=%Domain\20Users@internal)))] (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_cached_rules_by_user] (0x0400): Replacing sudoUser attribute with sudoUser: #1002201106 (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(sudoUser=+*)(!(|(sudoUser=ALL)(sudoUser=a-mdiorio@internal)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%Hosting_NetScaler_SuperUsers@internal)(sudoUser=%DB\20GreatPlains\20Admin@internal)(sudoUser=%NetScaler_SuperUsers@internal)(sudoUser=%USE5_SVN_FullAccess@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-9109@oldDomain.net)(sudoUser=%Enterprise\20Admins@internal)(sudoUser=%SQL\20Server\20Admins@internal)(sudoUser=%USE5_NetAppAdmins@internal)(sudoUser=%VI\20Administrators@internal)(sudoUser=%EDCMS_SQL_Admins@internal)(sudoUser=%DSBF_SQL_Admins@internal)(sudoUser=%EDPF_SQL_Admins@internal)(sudoUser=%Data\20Warehouse@internal)(sudoUser=%EDT_SQL_Admins@internal)(sudoUser=%GLS_SQL_Admins@internal)(sudoUser=%Backup\20Access@internal)(sudoUser=%DS_SQL_Admins@internal)(sudoUser=%Domain\20Admins@internal)(su doUser=%NetApp-Admins@internal)(sudoUser=%NetworkAdmins@internal)(sudoUser=%Schema\20Admins@internal)(sudoUser=%Domain\20Users@internal)(sudoUser=%SCCM_Admins@internal)(sudoUser=%CTX_Admins@internal)(sudoUser=%ESX\20Admins@internal)(sudoUser=%SQL_Admins@internal)(sudoUser=%UCS-Admins@internal)(sudoUser=%ConfigMgr\20Remote\20Control\20Users@internal)(sudoUser=%Denied\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%Backup\20Access@oldDomain.net)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-15027@oldDomain.net)(sudoUser=%SQL\20Server\20Admins@oldDomain.net)(sudoUser=%Data\20Warehouse@oldDomain.net)(sudoUser=%DB\20GreatPlains\20Admin@oldDomain.net)(sudoUser=%Domain\20Users@internal))))] (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for [a-mdiorio@internal@internal] (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): error: [0] (Tue Jan 31 16:52:19 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000): rules_num: [0] (Tue Jan 31 16:52:21 2017) [sssd[sudo]] [client_recv] (0x0200): Client disconnected! (Tue Jan 31 16:52:21 2017) [sssd[sudo]] [client_close_fn] (0x2000): Terminated client [0x7f150b43d090][20]
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Tue, Jan 31, 2017 at 05:06:30PM -0000, mdiorio@gmail.com wrote:
On Mon, Jan 30, 2017 at 06:45:19PM -0000, mdiorio(a)gmail.com wrote:
Are your sudo rules stored in AD or locally in /etc/sudoers? I assume it's in AD, right?
Seems like this is the part I was missing. Not well explained AT ALL (or anywhere in any documentation I have been looking at)!
I extended AD and am creating the rules now. The one thing that I'm not sure of is: "Non-Unix group support is only available when an appropriate group_plugin is defined in the global defaults sudoRole object."
This means that all the groups you assign to the rule must be resolvable in the 'id' command with the vanilla sudo code.
So if I want to add an AD security group to the rule, how would that be done and is a plugin needed?
As long as the the groups is resolvable by the client, then no. The plugin would do the work of asserting the user is a member of the group -- as long as the usual NSS interface can be used, no plugin is needed.
So I have a security group GS-Technology, I'd enter it as %GS-Technology? What about group with spaces like Domain Admins? Would it be %Domain\ Admins, or do I need to do the domain too? Escaping the ?
A group name must start with a percent sign, that's how it's determined that it's a group and not a user.
As per the name format, I agree we can document this better, feel free to open a bug against sssd. The answer depends on the sssd version, up and until 1.13 it would be just the short name (e.g. %GS-Technology), starting with 1.14, the name can also be qualified (%GS-Technology@your.ad.domain). The format of the 'qualified' name must be parseable by sssd as per the re_expression command.
No escaping, that's a shell thing and has no place in LDAP.
%INTERNAL\Domain\ Admins
Documentation is not very firm in this area.
So this is getting somewhat strange. Here is my process:
1) Change the entry format in AD. 2) Invalidate the cache with sss_cache -E 3) Delete the cache database ldb file 4) Restart SSSD 5) Run an ldbsearch to verify the cached entries have changed. 6) Log in and run a sudo -l
That seems logical to me, as the cache never changed without first deleting the ldb file even though my timeout is 5 seconds.
For reference, here's the id of my account: [[LAColo] root@la-1pelkes01 sssd]# id a-mdiorio uid=1002201106(a-mdiorio) gid=1002200513(domain users) groups=1002200513(domain users),1467609109(s-1-5-21-1675524420-526404074-825688854-9109@olddomain.net),1002202075(ds_sql_admins),1002201716(sql server admins),1002202175(netapp-admins),1002202168(navisite_netscaler_superusers),1002201311(sccm_admins),1002201492(db greatplains admin),1002201331(ctx_admins),1467615027,1467602102(backup access@olddomain.net),1467603840(data warehouse@olddomain.net),1002200571(allowed rodc password replication group),1002202083(edpf_sql_admins),1002200512(domain admins),1002202116(networkadmins),1002201751(vi administrators),1002202085(edcms_sql_admins),1467602532(db greatplains admin@olddomain.net),1002203128(configmgr remote control users),1002200519(enterprise admins),1002202078(dsbf_sql_admins),1002202087(edt_sql_admins),1002202176(ucs-admins),1002201742(use5_netappadmins),1467601948(sql server admins@olddomain.net),1002200572(denied rodc password replication group),1002201744(use5_svn_fullaccess ),1002200518(schema admins),1002201475(data warehouse),1002202180(esx admins),1002202074(gls_sql_admins),1002201327(sql_admins),1002201439(backup access),1002202242(netscaler_superusers)
This look very normal, and you can see domain admins in the list. Perfect 1002200512(domain admins)
So I log in and test, and get a sudo failure. OK. I tail the end of the sssd_sudo log file and see that it's now using SID's in the query instead of group names.
(Wed Feb 1 09:52:59 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(sudoUser=+*)(!(|(sudoUser=ALL)(sudoUser=a-mdiorio@internal)(sudoUser=#1002201106)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-9109@olddomain.net)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2075@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1716@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2175@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2168@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1311@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1492@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1331@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-15027@olddomain.net)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-2102@olddomain.net)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-3840@olddomain.net)(sudoUser=%S-1-5-21-2509590173-3389988914-249825 9327-571@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2083@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-512@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2116@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1751@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2085@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-2532@olddomain.net)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-3128@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-519@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2078@internal)(sudoUser=%Domain\20Users@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2176@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1742@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-1948@olddomain.net)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-572@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1744@internal)(su doUser=%S-1-5-21-2509590173-3389988914-2498259327-518@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1475@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2180@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2074@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1327@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1439@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2242@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2087@internal)(sudoUser=%Domain\20Users@internal))))]
Very strange. I give it about 20 minutes and test again, and now the sudo search has resolved the SID to group names properly. Oddly, Domain Users group always resolves immediately, never a SID. Even logging off and back in doesn't force the SID to name conversion.
(Wed Feb 1 10:07:02 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(sudoUser=+*)(!(|(sudoUser=ALL)(sudoUser=a-mdiorio@internal)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%NaviSite_NetScaler_SuperUsers@internal)(sudoUser=%DB\20GreatPlains\20Admin@internal)(sudoUser=%USE5_SVN_FullAccess@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-9109@olddomain.net)(sudoUser=%Enterprise\20Admins@internal)(sudoUser=%SQL\20Server\20Admins@internal)(sudoUser=%USE5_NetAppAdmins@internal)(sudoUser=%VI\20Administrators@internal)(sudoUser=%EDCMS_SQL_Admins@internal)(sudoUser=%DSBF_SQL_Admins@internal)(sudoUser=%EDPF_SQL_Admins@internal)(sudoUser=%Data\20Warehouse@internal)(sudoUser=%EDT_SQL_Admins@internal)(sudoUser=%GLS_SQL_Admins@internal)(sudoUser=%Backup\20Access@internal)(sudoUser=%DS_SQL_Admins@internal)(sudoUser=%Domain\20Admins@internal)(sudoUser=%NetApp-Admins@internal)(sudoUser =%NetworkAdmins@internal)(sudoUser=%Schema\20Admins@internal)(sudoUser=%Domain\20Users@internal)(sudoUser=%SCCM_Admins@internal)(sudoUser=%CTX_Admins@internal)(sudoUser=%ESX\20Admins@internal)(sudoUser=%SQL_Admins@internal)(sudoUser=%UCS-Admins@internal)(sudoUser=%ConfigMgr\20Remote\20Control\20Users@internal)(sudoUser=%Denied\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%NetScaler_SuperUsers@internal)(sudoUser=%Backup\20Access@olddomain.net)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-15027@olddomain.net)(sudoUser=%SQL\20Server\20Admins@olddomain.net)(sudoUser=%Data\20Warehouse@olddomain.net)(sudoUser=%DB\20GreatPlains\20Admin@olddomain.net)(sudoUser=%Domain\20Users@internal))))]
Notice that it is putting \20 in in the group name where there is a space in the log. This feels like a bug or at least a timing issue. It's not asking AD to resolve SID to name.
And another revelation, instead of waiting for it to resolve, I can do an 'id username' and it will convert all the groups to names immediately.
So in the end, %Domain Admins is the correct format for groups with spaces in the name. $GS-Technology was the correct name for the standard group.
I also created a nisNetgroup in AD with a nisNetgroup Triple in the format (serverName,,domainname) and added the nisNetgroup to the sudo rule using the format +nisNetgroup and it's all working properly!
I think the biggest issue was the SID to name resolution and not waiting long enough for it to resolve. I tried something, failed, tried another thing, failed, got interrupted, came back and it worked, but wasn't sure what I did that made it work, then started backing out changed and not waiting long enough again.
So the biggest pain is going to be adding the linux servers manually to the nisNetgroup instead of using a standard Windows security group. Is there a possible feature improvement to get this functionality to work? We're going to be using a rapid prototyping environment and it'd probably be easier adding systems to a standard windows group vs a netgroup.
On Wed, Feb 01, 2017 at 03:45:52PM -0000, mdiorio@gmail.com wrote:
So this is getting somewhat strange. Here is my process:
- Change the entry format in AD.
- Invalidate the cache with sss_cache -E
- Delete the cache database ldb file
- Restart SSSD
- Run an ldbsearch to verify the cached entries have changed.
- Log in and run a sudo -l
That seems logical to me, as the cache never changed without first deleting the ldb file even though my timeout is 5 seconds.
For reference, here's the id of my account: [[LAColo] root@la-1pelkes01 sssd]# id a-mdiorio uid=1002201106(a-mdiorio) gid=1002200513(domain users) groups=1002200513(domain users),1467609109(s-1-5-21-1675524420-526404074-825688854-9109@olddomain.net),1002202075(ds_sql_admins),1002201716(sql server admins),1002202175(netapp-admins),1002202168(navisite_netscaler_superusers),1002201311(sccm_admins),1002201492(db greatplains admin),1002201331(ctx_admins),1467615027,1467602102(backup access@olddomain.net),1467603840(data warehouse@olddomain.net),1002200571(allowed rodc password replication group),1002202083(edpf_sql_admins),1002200512(domain admins),1002202116(networkadmins),1002201751(vi administrators),1002202085(edcms_sql_admins),1467602532(db greatplains admin@olddomain.net),1002203128(configmgr remote control users),1002200519(enterprise admins),1002202078(dsbf_sql_admins),1002202087(edt_sql_admins),1002202176(ucs-admins),1002201742(use5_netappadmins),1467601948(sql server admins@olddomain.net),1002200572(denied rodc password replication group),1002201744(use5_svn_fullaccess ),1002200518(schema admins),1002201475(data warehouse),1002202180(esx admins),1002202074(gls_sql_admins),1002201327(sql_admins),1002201439(backup access),1002202242(netscaler_superusers)
This look very normal, and you can see domain admins in the list. Perfect 1002200512(domain admins)
So I log in and test, and get a sudo failure. OK. I tail the end of the sssd_sudo log file and see that it's now using SID's in the query instead of group names.
(Wed Feb 1 09:52:59 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(sudoUser=+*)(!(|(sudoUser=ALL)(sudoUser=a-mdiorio@internal)(sudoUser=#1002201106)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-9109@olddomain.net)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2075@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1716@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2175@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2168@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1311@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1492@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1331@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-15027@olddomain.net)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-2102@olddomain.net)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-3840@olddomain.net)(sudoUser=%S-1-5-21-2509590173-3389988914-249825 9327-571@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2083@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-512@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2116@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1751@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2085@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-2532@olddomain.net)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-3128@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-519@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2078@internal)(sudoUser=%Domain\20Users@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2176@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1742@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-1948@olddomain.net)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-572@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1744@internal)(su doUser=%S-1-5-21-2509590173-3389988914-2498259327-518@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1475@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2180@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2074@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1327@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-1439@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2242@internal)(sudoUser=%S-1-5-21-2509590173-3389988914-2498259327-2087@internal)(sudoUser=%Domain\20Users@internal))))]
Very strange. I give it about 20 minutes and test again, and now the sudo search has resolved the SID to group names properly. Oddly, Domain Users group always resolves immediately, never a SID. Even logging off and back in doesn't force the SID to name conversion.
(Wed Feb 1 10:07:02 2017) [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(sudoUser=+*)(!(|(sudoUser=ALL)(sudoUser=a-mdiorio@internal)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%NaviSite_NetScaler_SuperUsers@internal)(sudoUser=%DB\20GreatPlains\20Admin@internal)(sudoUser=%USE5_SVN_FullAccess@internal)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-9109@olddomain.net)(sudoUser=%Enterprise\20Admins@internal)(sudoUser=%SQL\20Server\20Admins@internal)(sudoUser=%USE5_NetAppAdmins@internal)(sudoUser=%VI\20Administrators@internal)(sudoUser=%EDCMS_SQL_Admins@internal)(sudoUser=%DSBF_SQL_Admins@internal)(sudoUser=%EDPF_SQL_Admins@internal)(sudoUser=%Data\20Warehouse@internal)(sudoUser=%EDT_SQL_Admins@internal)(sudoUser=%GLS_SQL_Admins@internal)(sudoUser=%Backup\20Access@internal)(sudoUser=%DS_SQL_Admins@internal)(sudoUser=%Domain\20Admins@internal)(sudoUser=%NetApp-Admins@internal)(sudoUser =%NetworkAdmins@internal)(sudoUser=%Schema\20Admins@internal)(sudoUser=%Domain\20Users@internal)(sudoUser=%SCCM_Admins@internal)(sudoUser=%CTX_Admins@internal)(sudoUser=%ESX\20Admins@internal)(sudoUser=%SQL_Admins@internal)(sudoUser=%UCS-Admins@internal)(sudoUser=%ConfigMgr\20Remote\20Control\20Users@internal)(sudoUser=%Denied\20RODC\20Password\20Replication\20Group@internal)(sudoUser=%NetScaler_SuperUsers@internal)(sudoUser=%Backup\20Access@olddomain.net)(sudoUser=%S-1-5-21-1675524420-526404074-825688854-15027@olddomain.net)(sudoUser=%SQL\20Server\20Admins@olddomain.net)(sudoUser=%Data\20Warehouse@olddomain.net)(sudoUser=%DB\20GreatPlains\20Admin@olddomain.net)(sudoUser=%Domain\20Users@internal))))]
Notice that it is putting \20 in in the group name where there is a space in the log. This feels like a bug or at least a timing issue. It's not asking AD to resolve SID to name.
And another revelation, instead of waiting for it to resolve, I can do an 'id username' and it will convert all the groups to names immediately.
Right, that's actually a good analysis.
When the AD provider is in use and ID mapping is enabled, we are able to get all the SIDs the user is a member of by fetching an attribute called tokenGroups and mapping the IDs from SIDs directly. In this case, we temporarily save the group objects with name=$SID until a subsequent call resolves the IDs to names. That's why you see the SIDs in the name attribute. But I would expect the client (sudo in this case) to resolve the GIDs to names itself since the client asserts if any of the user's group names is in the list of sudo rules returned from sssd.
As a quick workaround, you can try using: ldap_use_tokengroups = false which would save the groups and resolve the names.
I think I spotted something similar only with a certain older sudo version: https://bugzilla.redhat.com/show_bug.cgi?id=1372440
I really wonder if the sudo responder should be on the safe side in this scenario and resolve the user's groups to make sure we don't depend on sudo itself doing the translation.
SSSD developers, do you have any opinion?
So in the end, %Domain Admins is the correct format for groups with spaces in the name. $GS-Technology was the correct name for the standard group.
I also created a nisNetgroup in AD with a nisNetgroup Triple in the format (serverName,,domainname) and added the nisNetgroup to the sudo rule using the format +nisNetgroup and it's all working properly!
Thank you for testing, do you think it might be a good addition to: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server ?
I think the biggest issue was the SID to name resolution and not waiting long enough for it to resolve. I tried something, failed, tried another thing, failed, got interrupted, came back and it worked, but wasn't sure what I did that made it work, then started backing out changed and not waiting long enough again.
Please try if disabling the tokengroups optimization helps here.
So the biggest pain is going to be adding the linux servers manually to the nisNetgroup instead of using a standard Windows security group. Is there a possible feature improvement to get this functionality to work? We're going to be using a rapid prototyping environment and it'd probably be easier adding systems to a standard windows group vs a netgroup.
I'm not sure if sudo (or Linux systems in general) support any other host-grouping mechanism than netgroups..
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
mdiorio＠gmail.com