다른 제안의 문제점은
- 회사 LAN (또는 VPN)에 액세스 할 수있는 경우에만 작동합니다
- 항상 모든 컴퓨터에서 sudoers 파일을 유지해야합니다
- 보너스로, 그들은 나를 위해 일하지 않았다-전혀
대신, 나는 뭔가를 원했다
- 신임 정보와 sudo 액세스를 모두 캐시합니다.
- 중앙 관리
실제 솔루션은 SSSD를 사용하고 AD 스키마를 확장하는 것입니다. 이렇게하면 SSSD는 AD에서 sudo 설정 및 사용자 자격 증명을 주기적으로 가져 와서 로컬 캐시를 유지 관리합니다. 그런 다음 sudo 규칙은 AD 개체에 저장되어 워크 스테이션의 sudoers 파일을 건드리지 않고도 컴퓨터, 사용자 및 명령으로 규칙을 제한 할 수 있습니다.
정확한 튜토리얼은 여기에 설명하기에는 너무 길지만 자동화에 도움이되는 단계별 가이드와 일부 스크립트를 찾을 수 있습니다.
TL; DR :
기원 후
최신 버전 잡고 는 sudo를 얻가, 문서 / schema.ActiveDirectory 다음 (도메인 이름에 따라 도메인 경로를 수정해야합니다)를 가져, 파일 :
ldifde -i -f schema.ActiveDirectory -c "CN=Schema,CN=Configuration,DC=X" "CN=Schema,CN=Configuration,DC=ad,DC=foobar,DC=com" -j .
ADSI 편집으로이를 확인하십시오. 스키마 이름 지정 컨텍스트를 열고 sudoRole 클래스를 찾으십시오 .
이제 도메인 루트에 sudoers OU를 작성하십시오 .이 OU는 모든 Linux 워크 스테이션에 대한 모든 sudo 설정을 보유합니다. 이 OU에서 sudoRole 객체를 만듭니다. sudoRole 개체를 만들려면 ADSI 편집을 사용해야하지만 일단 만들어진 후에는 Active Directory 사용자 및 컴퓨터 를 사용하여 수정할 수 있습니다.
하자 내가 컴퓨터 이름이 있다고 가정 foo32linux , 사용자라는 stewie.griffin을 하고 나는 그에게 그 빌려 sudo는 모든 명령을 실행할 수 있도록합니다. 이 경우 sudoers OU 아래에 sudoRole 객체를 만듭니다 . sudoRole의 경우 원하는 모든 이름을 사용할 수 있습니다. 컴퓨터 별 규칙을 사용하기 때문에 컴퓨터 이름을 고수합니다. 이제 다음과 같이 속성을 설정하십시오.
- sudoHost : foo32linux
- sudoCommand : 모두
- sudoUser : stewie.griffin
명령의 경우 / bin / less 또는 기타 와 같은 특정 항목도 사용할 수 있습니다 .
SSSD
최소한 /etc/sssd/sssd.conf에 추가하십시오 :
[sssd]
services = nss, pam, sudo
[domain/AD.FOOBAR.COM]
cache_credentials = True
SSSD는 몇 시간마다 업데이트 된 규칙으로 로컬 캐시를 새로 고치지 만 테스트하는 가장 간단한 방법은 컴퓨터를 재부팅하는 것입니다. 그런 다음 AD 사용자로 로그인하여 다음을 확인하십시오.
sudo -l
해당 사용자 및 컴퓨터에 추가 한 모든 관련 항목이 나열되어야합니다. 쉬워요!
%Domain^Admins ALL=(ALL) ALL