On Wed, Feb 01, 2017 at 03:45:52PM -0000, mdiorio(a)gmail.com wrote:
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(a)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(a)olddomain.net),1467603840(data warehouse(a)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(a)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(a)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(a)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(a)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(a)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(a)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..