On 23/09/13 11:40, Ondrej Valousek wrote:
Great. could you share with us the procedure you used to extend AD
schema?
Thanks, a lot.
Ondrej
________________________________________
From: sssd-users-bounces(a)lists.fedorahosted.org
[sssd-users-bounces(a)lists.fedorahosted.org] on behalf of Rowland Penny
[repenny241155(a)gmail.com]
Sent: Monday, September 23, 2013 12:17 PM
To: End-user discussions about the System Security Services Daemon
Subject: Re: [SSSD-users] sssd and sudo [SOLVED]
On 23/09/13 09:51, Pavel Březina wrote:
> On 09/21/2013 04:38 PM, Rowland Penny wrote:
>> On 20/09/13 08:36, Pavel Březina wrote:
>>> On 09/19/2013 06:18 PM, Rowland Penny wrote:
>>>> Ok, I am back again, trying to get sssd to control sudo, but failing.
>>>>
>>>> I added the sudo active directory schema ldif to samba4 AD
>>>>
>>>> then added this:
>>>>
>>>> dn: OU=SUDOers,DC=example,DC=com
>>>> objectClass: top
>>>> objectClass: organizationalUnit
>>>> ou: SUDOers
>>>>
>>>> dn: CN=linuxusers,OU=SUDOers,DC=example,DC=com
>>>> objectClass: top
>>>> objectClass: sudoRole
>>>> cn: linuxusers
>>>> sudoUser: %linuxusers
>>>> sudoHost: ALL
>>>> sudoCommand: ALL
>>>>
>>>> On a Linux Mint client:
>>>>
>>>> sudo apt-get install sudo-ldap
>>>>
>>>> Edited /etc/sudo-ldap.conf
>>>>
>>>> # TLS certificates (needed for GnuTLS)
>>>> TLS_CACERT /etc/ssl/certs/ca-certificates.crt
>>>> BASE DC=example,DC=com
>>>> URI
ldap://server.example.com
>>>> ssl=no
>>>> LDAP_VERSION 3
>>>> SUDOERS_BASE ou=SUDOers,DC=example,DC=com
>>>> SUDOERS_SEARCH_FILTER (&(objectClass=sudoRole))
>>>> BINDDN CN=Administrator,CN=Users,DC=example,DC=com
>>>> BINDPW xxxxxxxxxx
>>>>
>>>> then edited /etc/nsswitch.conf and added
>>>>
>>>> sudoers: files ldap
>>>>
>>>> restarted sudo
>>>>
>>>> then as a normal user, tried to run a command with sudo, this worked.
>>>>
>>>> I then altered /etc/sssd/sssd.conf and added
>>>>
>>>> services = nss, pam, autofs, sudo
>>>>
>>>> [sudo]
>>>>
>>>> ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com
>>>>
>>>> altered /etc/nsswitch.conf
>>>>
>>>> sudoers: files sss
>>>>
>>>> restarted sssd
>>>> restarted sudo
>>>>
>>>> tried to run the command with sudo again, this time it failed
>>>>
>>>> having been bitten by the way autofs works, I went straight to the way
>>>> that sudo & sssd do the ldapsearch:
>>>>
>>>> SUDO
>>>> (&(&(objectClass=sudoRole))(|(sudoUser=rowland)(sudoUser=%Domain
>>>>
Users)(sudoUser=%#20513)(sudoUser=%vboxusers)(sudoUser=%linuxusers)(sudoUser=%#127)(sudoUser=%#21110)(sudoUser=ALL)))
>>>>
>>>>
>>>>
>>>>
>>>> SSSD
>>>>
(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.home.lan)(sudoHost=192.168.0.204)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*))))
>>>>
>>>>
>>>>
>>>>
>>>> sudo searches with objectClass=sudoRole & sudoUser attribute
>>>> sssd searches with objectClass=sudoRole & sudoHost attribute
>>>>
>>>> Now I understand that the sssd search for the sudoHost attribute is to
>>>> ensure that only sudo rules for the host are downloaded, but it
>>>> doesn't
>>>> actually seem to download any rules.
>>>>
>>>> Is there anyway I can get the sssd search to include the sudoUser
>>>> attribute in the same way that the sudo ldap search does?
>>> Hi,
>>> no, it is not desirable. SSSD periodically downloads all rules that
>>> are applicable to the machine, and then filters them by user when sudo
>>> request is performed. In other words: filtering by sudoUser is there,
>>> only on other place (sssd_sudo process).
>>>
>>> Can you send us (sanitized or privately if you want) your complete
>>> sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?
>>>
>>>> Or can anybody tell me where I am going wrong (again).
>>>>
>>>> Rowland
>>> _______________________________________________
>>> sssd-users mailing list
>>> sssd-users(a)lists.fedorahosted.org
>>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> Hi,
>
>> OK, I have now got sssd to cache the sudo rules from AD, I found out
>> that you must have 'defaults' in the AD database, I didn't and
thought
>> you could just use the defaults on the client.
> having cn=defaults in LDAP is not necessary. From the logs you've sent
> me, I can see that three rules were stored in the cache.
>
> If the rules are not stored when cn=defaults is missing, it is a bug.
> However, I am unable to reproduce it.
>
>> Now, even though sssd has cached the rules, I still cannot get an AD
>> user to run a command as the root user.
>>
>> Anybody got any further ideas? or to put it another way, HELPPPPP!!!!!!
> Please, see my earlier response.
>
>> Rowland
>
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi, I am fairly sure that I have fixed my problem, it is not a sssd
problem, it is an ubuntu problem.
I was using 'sudo-ldap' as you need this to connect via ldap, so I
assumed I needed it to connect via sssd, this it would seem is wrong.
On:
https://launchpad.net/ubuntu/+source/sudo/+changelog
I found this:
1.8.6p3-0ubuntu1
Superseded in raring-release on 2012-12-08
Deleted in raring-proposed on 2012-12-09 (Reason: moved to release)
sudo (1.8.6p3-0ubuntu1) raring; urgency=low
* New upstream release (1.8.6p3).
* Add patch to fix building with sssd when ldap is disabled.
* Drop sudo.manpages and sudo-ldap.manpages as the upstream build system
now does the right thing here.
* Build the main sudo package with support for sssd, this doesn't add any
additional build time or runtime dependency. sudo will dynamically load
the sssd library if 'sss' is listed for the 'sudoers' nss service.
-- Stephane Graber <email address hidden> Fri, 16 Nov 2012 09:31:32
-0500
Hmm, the 'sudo' package seems to be built to connect to sssd.
Re-installed the 'sudo' package and it now seems to work, so I can only
surmise that the 'sudo-ldap' package isn't built to connect to sssd for
whatever reason.
It would make more sense to build (well to me anyway) a 'sudo-sssd'
package OR just one 'sudo' package.
Rowland
Rowland
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users OK, to add sudo to sssd
on samba4, you need the following ldifs:
sudo_attr.ldif
dn: CN=sudoUser,CN=Schema,CN=Configuration,DC=example,DC=com
objectClass: top
objectClass: attributeSchema
attributeID: 1.3.6.1.4.1.15953.9.1.1
schemaIDGUID:: JrGcaKpnoU+0s+HgeFjAbg==
cn: sudoUser
name: sudoUser
lDAPDisplayName: sudoUser
adminDisplayName: sudoUser
adminDescription: User(s) who may run sudo
attributeSyntax: 2.5.5.5
isSingleValued: FALSE
showInAdvancedViewOnly: TRUE
oMSyntax: 22
searchFlags: 1
dn: CN=sudoHost,CN=Schema,CN=Configuration,DC=example,DC=com
objectClass: top
objectClass: attributeSchema
attributeID: 1.3.6.1.4.1.15953.9.1.2
schemaIDGUID:: d0TTjg+Y6U28g/Y+ns2k4w==
cn: sudoHost
name: sudoHost
lDAPDisplayName: sudoHost
adminDisplayName: sudoHost
adminDescription: Host(s) who may run sudo
attributeSyntax: 2.5.5.5
isSingleValued: FALSE
showInAdvancedViewOnly: TRUE
oMSyntax: 22
dn: CN=sudoCommand,CN=Schema,CN=Configuration,DC=example,DC=com
objectClass: top
objectClass: attributeSchema
attributeID: 1.3.6.1.4.1.15953.9.1.3
schemaIDGUID:: D6QR4P5UyUen3RGYJCHCPg==
cn: sudoCommand
name: sudoCommand
lDAPDisplayName: sudoCommand
adminDisplayName: sudoCommand
adminDescription: Command(s) to be executed by sudo
attributeSyntax: 2.5.5.5
isSingleValued: FALSE
showInAdvancedViewOnly: TRUE
oMSyntax: 22
dn: CN=sudoRunAs,CN=Schema,CN=Configuration,DC=example,DC=com
objectClass: top
objectClass: attributeSchema
attributeID: 1.3.6.1.4.1.15953.9.1.4
schemaIDGUID:: CP98mCQTyUKKxGrQeM80hQ==
cn: sudoRunAs
name: sudoRunAs
lDAPDisplayName: sudoRunAs
adminDisplayName: sudoRunAs
adminDescription: User(s) impersonated by sudo (deprecated)
attributeSyntax: 2.5.5.5
isSingleValued: FALSE
showInAdvancedViewOnly: TRUE
oMSyntax: 22
dn: CN=sudoOption,CN=Schema,CN=Configuration,DC=example,DC=com
objectClass: top
objectClass: attributeSchema
attributeID: 1.3.6.1.4.1.15953.9.1.5
schemaIDGUID:: ojaPzBBlAEmsvrHxQctLnA==
cn: sudoOption
name: sudoOption
lDAPDisplayName: sudoOption
adminDisplayName: sudoOption
adminDescription: Option(s) followed by sudo
attributeSyntax: 2.5.5.5
isSingleValued: FALSE
showInAdvancedViewOnly: TRUE
oMSyntax: 22
dn: CN=sudoRunAsUser,CN=Schema,CN=Configuration,DC=example,DC=com
objectClass: top
objectClass: attributeSchema
attributeID: 1.3.6.1.4.1.15953.9.1.6
schemaIDGUID:: 9C52yPYd3RG3jMR2VtiVkw==
cn: sudoRunAsUser
name: sudoRunAsUser
lDAPDisplayName: sudoRunAsUser
adminDisplayName: sudoRunAsUser
adminDescription: User(s) impersonated by sudo
attributeSyntax: 2.5.5.5
isSingleValued: FALSE
showInAdvancedViewOnly: TRUE
oMSyntax: 22
dn: CN=sudoRunAsGroup,CN=Schema,CN=Configuration,DC=example,DC=com
objectClass: top
objectClass: attributeSchema
attributeID: 1.3.6.1.4.1.15953.9.1.7
schemaIDGUID:: xJhSt/Yd3RGJPTB1VtiVkw==
cn: sudoRunAsGroup
name: sudoRunAsGroup
lDAPDisplayName: sudoRunAsGroup
adminDisplayName: sudoRunAsGroup
adminDescription: Groups(s) impersonated by sudo
attributeSyntax: 2.5.5.5
isSingleValued: FALSE
showInAdvancedViewOnly: TRUE
oMSyntax: 22
dn: CN=sudoNotBefore,CN=Schema,CN=Configuration,DC=example,DC=com
objectClass: top
objectClass: attributeSchema
attributeID: 1.3.6.1.4.1.15953.9.1.8
schemaIDGUID:: dm1HnRfY4RGf4gopYYhwmw==
cn: sudoNotBefore
name: sudoNotBefore
lDAPDisplayName: sudoNotBefore
adminDisplayName: sudoNotBefore
adminDescription: Start of time interval for which the entry is valid
attributeSyntax: 2.5.5.11
isSingleValued: TRUE
showInAdvancedViewOnly: TRUE
oMSyntax: 24
dn: CN=sudoNotAfter,CN=Schema,CN=Configuration,DC=example,DC=com
objectClass: top
objectClass: attributeSchema
attributeID: 1.3.6.1.4.1.15953.9.1.9
schemaIDGUID:: OAr/pBfY4RG9dBIpYYhwmw==
cn: sudoNotAfter
name: sudoNotAfter
lDAPDisplayName: sudoNotAfter
adminDisplayName: sudoNotAfter
adminDescription: End of time interval for which the entry is valid
attributeSyntax: 2.5.5.11
isSingleValued: TRUE
showInAdvancedViewOnly: TRUE
oMSyntax: 24
dn: CN=sudoOrder,CN=Schema,CN=Configuration,DC=example,DC=com
objectClass: top
objectClass: attributeSchema
attributeID: 1.3.6.1.4.1.15953.9.1.10
schemaIDGUID:: 0J8yrRfY4RGIYBUpYYhwmw==
cn: sudoOrder
name: sudoOrder
lDAPDisplayName: sudoOrder
adminDisplayName: sudoOrder
adminDescription: an integer to order the sudoRole entries
attributeSyntax: 2.5.5.9
isSingleValued: TRUE
showInAdvancedViewOnly: TRUE
oMSyntax: 2
sudo_class.ldif
dn: CN=sudoRole,CN=Schema,CN=Configuration,DC=example,DC=com
objectClass: top
objectClass: classSchema
governsID: 1.3.6.1.4.1.15953.9.2.1
schemaIDGUID:: SQn432lnZ0+ukbdh3+gN3w==
cn: sudoRole
name: sudoRole
lDAPDisplayName: sudoRole
possSuperiors: container
possSuperiors: top
subClassOf: top
mayContain: sudoCommand
mayContain: sudoHost
mayContain: sudoOption
mayContain: sudoRunAs
mayContain: sudoRunAsUser
mayContain: sudoRunAsGroup
mayContain: sudoUser
mayContain: sudoNotBefore
mayContain: sudoNotAfter
mayContain: sudoOrder
showInAdvancedViewOnly: FALSE
adminDisplayName: sudoRole
adminDescription: Sudoer Entries
objectClassCategory: 1
systemOnly: FALSE
defaultObjectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=home,DC=lan
Stop samba 4
add the sudo_attr.ldif and then the sudo_class.ldif, see:
https://wiki.samba.org/index.php/Samba4/Schema_extenstions
Rowland