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.
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.