[Samba] rid mapping works on member server but not DC

[Rowland Penny]

On 12/04/15 18:08, Jonathan Hunter wrote:
> On 12 April 2015 at 14:34, Rowland Penny <rowlandpenny at googlemail.com> wrote:
>>> - perhaps use sssd? (which I haven't yet investigated, to be honest)
>> You could try sssd, this has a backend like the winbind backend and will
>> also work on the DC (well it did the last time I tried it, which was some
>> time ago) .
> Thanks! I'm looking at
> https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server at
> the moment. Looks like I can either use 'net join ...' (which I
> suspect won't work when I'm running it from my DC already, with its
> existing DC role smb.conf), or manually grab a Kerberos ticket
> somehow.

You only join a member server or client to the DC, you never join the DC 
to itself.

>
> One of the steps for that is ''ktpass /princ host/..." but I'm not
> sure if running that will affect the functionality of my existing DC.
> Do you remember what steps you used when you tried last? I can't
> immediately find any info from other folks who may already be running
> sssd on a Samba DC :(

After a quick check of my old scripts, I believe you only need to setup 
the samba 4 AD DC as normal, install sssd and export the DCs keytab.

samba-tool domain exportkeytab /etc/krb5.keytab -U Administrator

then setup /etc/sssd/sssd.conf something like this:

[sssd]
services = nss, pam
config_file_version = 2
domains = example.com

[nss]

[pam]

[domain/example.com]
# Once sure everything working OK
# Change line below to false
enumerate = true
cache_credentials = true
# uncomment line below if using uid/gidNumber
#ldap_id_mapping = false
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad

chmod 0600 /etc/sssd/sssd.conf

service sssd start

then try getent :-)

Rowland

>>> I was reluctant to go down the 'ad' backend route simply because from
>>> what I can see, there is then the risk of a Windows admin for any part
>>> of the AD tree being able to 'impersonate' any UNIX user by simply
>>> [...]
>> All things come with risks, do you really not trust your co-workers ?? Also
>> there are probably easier ways of getting access to users data.
> More that somebody from one part of the organisation could interfere
> with another part of the organisation via AD (which wouldn't be the
> same using algorithmic RID). That's a separate question though, and
> I'm happy to believe that I am over-thinking!
>
> Thanks :)
>
> J
>