sssd + AD (samba) id mapping in multi-OS environment

[Zdravko Zdravkov]

I have working AD (Samba) for office with mostly Linux machines and few
users on Windows 10.
I'm using sssd to join the AD with the following configuration:

[sssd]
> domains = xxxxx
> config_file_version = 2
> services = nss, pam
> [domain/xxxxx]
> ad_domain = xxxxxx
> krb5_realm = XXXXXXX
> realmd_tags = manages-system joined-with-samba
> cache_credentials = True
> id_provider = ad
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> ldap_id_mapping = True
> use_fully_qualified_names = False
> fallback_homedir = /home/%u
> access_provider = ad

We have EMC storage, joined to the AD. Everyone is using it. On Windows
it's being mapped via smb, and in Linux via nfs.

I'll explain it as simple as I can. If I'm Linux user X and I create folder
on the storage then list it to check ownership and permissions, it appears
as it should - with owner X, and group domain users.

Next, I log on Windows machine with the same user (X), browse the storage
and create another folder. Then, on a Linux machine I list it, to check
ownership. Now for owner I'm getting bizarre generated uID - "1000043", but
the group remains as it should (domain users). Obviously this is a problem,
as it messes up access to files/folders which need to be used between
different operating systems.
Next, from linux machine I check the uid for that particular user: *id X*,
so I'm getting result "1115001239" which is OK. This is the uid as Linux
understands it.
If I copy that uid, then in AD users and computers management tool (in
windows) I browse that particular user, and manually add the uid to the
shown uidNumber attribute:

[image: ad_attrs.PNG]

Then clear SSSD cache with *sss_cache -E*.
The next file/folder I create from Windows is now successfully shown with
correct owner name in Linux.
This is kind of a solution, but isn't perfect as it requires a bit of
manual interaction. I'm wondering if it has anything to do with SSSD, or it
is purely up to Samba? Is there a better way to achieve what I want.

Cheers guys

[Sumit Bose]

On Fri, Jan 11, 2019 at 11:53:45AM +0200, Zdravko Zdravkov wrote:
> I have working AD (Samba) for office with mostly Linux machines and few
> users on Windows 10.
> I'm using sssd to join the AD with the following configuration:
>
> [sssd]
> > domains = xxxxx
> > config_file_version = 2
> > services = nss, pam
> > [domain/xxxxx]
> > ad_domain = xxxxxx
> > krb5_realm = XXXXXXX
> > realmd_tags = manages-system joined-with-samba
> > cache_credentials = True
> > id_provider = ad
> > krb5_store_password_if_offline = True
> > default_shell = /bin/bash
> > ldap_id_mapping = True
> > use_fully_qualified_names = False
> > fallback_homedir = /home/%u
> > access_provider = ad
>
> We have EMC storage, joined to the AD. Everyone is using it. On Windows
> it's being mapped via smb, and in Linux via nfs.
>
> I'll explain it as simple as I can. If I'm Linux user X and I create folder
> on the storage then list it to check ownership and permissions, it appears
> as it should - with owner X, and group domain users.
>
> Next, I log on Windows machine with the same user (X), browse the storage
> and create another folder. Then, on a Linux machine I list it, to check
> ownership. Now for owner I'm getting bizarre generated uID - "1000043", but
> the group remains as it should (domain users). Obviously this is a problem,
> as it messes up access to files/folders which need to be used between
> different operating systems.
> Next, from linux machine I check the uid for that particular user: *id X*,
> so I'm getting result "1115001239" which is OK. This is the uid as Linux
> understands it.
> If I copy that uid, then in AD users and computers management tool (in
> windows) I browse that particular user, and manually add the uid to the
> shown uidNumber attribute:
>
> [image: ad_attrs.PNG]
>
> Then clear SSSD cache with *sss_cache -E*.
> The next file/folder I create from Windows is now successfully shown with
> correct owner name in Linux.

If I understand it correctly I would say that this is about how the EMC
storage gets the UID. With NFS it gets the UID used by the Linux client
from the protocol.  With SMB there is no UID in the protocol (there is a
POSX extension but I guess it is not used here) and I would expect that
the EMC system is configured to lookup user data from AD. As long as
there is not uidNumber stored in the user's AD object the storage has to
generate an UID on its own when making the files available via NFS.
> This is kind of a solution, but isn't perfect as it requires a bit of
> manual interaction. I'm wondering if it has anything to do with SSSD, or it
> is purely up to Samba? Is there a better way to achieve what I want.

How comes Samba into play here?

bye,
Sumit
> Cheers guys
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail].o...