Estou tendo problemas para fazer com que as regras de sudoers LDAP funcionem. Meu ambiente é:
Eu segui estas instruções para crie um sudo_debug.log (higienizado):
Jun 19 14:53:28 sudo[60452] Received 2 rule(s)
Jun 19 14:53:28 sudo[60452] -> sudo_sss_filter_result @ ./sssd.c:225
...
Jun 19 14:53:28 sudo[60452] sssd/ldap sudoHost 'ALL' ... MATCH!
...
Jun 19 14:53:28 sudo[60452] val[0]=%linuxadmins
...
Jun 19 14:53:28 sudo[60452] sudo_get_grlist: looking up group names for [email protected]
...
Jun 19 14:53:28 sudo[60452] sudo_getgrgid: gid 1157000513 [] -> group domain [email protected] [] (cache hit)
...
Jun 19 14:53:28 sudo[60452] user_in_group: user [email protected] NOT in group linuxadmins
Jun 19 14:53:28 sudo[60452] <- user_in_group @ ./pwutil.c:1031 := false
Jun 19 14:53:28 sudo[60452] user [email protected] matches group linuxadmins: false @ usergr_matches() ./match.c:969
Jun 19 14:53:28 sudo[60452] <- usergr_matches @ ./match.c:970 := false
Jun 19 14:53:28 sudo[60452] sssd/ldap sudoUser '%linuxadmins' ... not ([email protected])
...
Deste log, você pode ver isso:
linuxadmins group No entanto, o usuário está no grupo linuxadmins (higienizado, mas "usuário" corresponde):
$ getent group linuxadmins
[email protected]:*:1157001133:[email protected],[email protected]
A única coisa estranha sobre esse log é que sudo_get_grlist parece retornar apenas o grupo principal domain [email protected] do usuário. Isso explicaria a falta de um jogo.
Alguém já viu isso antes? Alguma idéia se a lista de grupos é resolvida dentro do sudo (que eu deveria continuar a esperar na minha pergunta para sudo-users ) ou em algum outro lugar como o SSSD (que eu deveria encontrar sua lista)?
Sim, a falta de grupos primários é provavelmente o problema. O fato de getent group funcionar é irrelevante, sudo usa a saída do initgroups, que é mais ou menos o que você recebe quando chama id .
E você também está certo de que o sssd-users é o melhor: link
Até consertamos nosso guia de solução de problemas há pouco tempo no link , o link direto é link
No CentOS 7, eu estava tendo o mesmo problema de id mostrando apenas grupos primários, por exemplo:
id DOMAIN\administrator
uid=485400500(administrator) gid=485400513(domain users) groups=485400513(domain users)
Eu estava lendo esta referência (link) e editando meu /etc/sssd/sssd.conf , e percebi que estava faltando algumas recomendações opções de configuração. Antes eu só tinha:
[domain/AD.DOMAIN]
id_provider = ad
então adicionei as outras bandeiras mencionadas pela referência abaixo:
auth_provider = ad
chpass_provider = ad
access_provider = ad
Infelizmente, não sei qual deles é responsável pela melhoria, mas se eu tivesse que adivinhar, seria auth_provider = ad . Agora id tem esse resultado:
id DOMAIN\administrator
uid=485400500(administrator) gid=485400513(domain users)
groups=485400513(domain users),485400518(schema admins),485400519(enterprise
admins),485400512(domain admins),485403117(sudoers),485400520(group policy
creator owners),485400572(denied rodc password replication
group),485401624(esx admins),485401679(wseremotewebaccessusers),
485401680(wseallowshareaccess),485401681(wseallowcomputeraccess),
485401682(wseallowmediaaccess),485401683(wseallowadd inaccess),485401684(wseallowdashboardaccess),
485401685(wseallowhomepagelinks),45401686(wsealertadministrators),
485401687(wseremoteaccessusers),485403103(ipamad mins)
Espero que ajude ...
Tags sudo active-directory sssd