HI all.
I've got working samba AD server. It is playing nicely with Windows 10 and also successfully authenticating Linux machines with SSSD. On the Windows machines I have our EMC storage smb mounted via group policy. Managing permissions for users and groups there, as you know, happens with right click, security etc..
As you may have already guessed the troubles come when my Linux machines, that access the storage via nfs mount, need to work with folders and files created from the Windows PCs. Linux doesn't "see" the actual user/group that owns given folder. It interprets it into ID numbers starting from 1000. I'm quite sure that this is common and known issue, but I don't know what is the right way to deal with it, so any wisdom will be helpful.
Here's smb.conf from server
[global]
netbios name = AD realm = XXXXXX server role = active directory domain controller server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl,
winbindd, ntp_signd, kcc, dnsupdate workgroup = XXXX idmap config XXXX:unix_nss_info = yes log file = /var/log/samba/samba.log log level = 3 [netlogon] path = /usr/local/samba/var/locks/sysvol/XXXXXX/scripts read only = No [sysvol] path = /usr/local/samba/var/locks/sysvol read only = No
also, sssd.conf from client
[sssd]
domains = xxxx config_file_version = 2 services = nss, pam [domain/xxxx] ad_domain = xxxx krb5_realm = XXXX 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
and nsswitch.conf
passwd: files sss
shadow: files sss group: files sss
Will appreciate any wisdom. Thanks! Z
On Mon, Apr 30, 2018 at 8:35 AM, Zdravko Zdravkov nirayah@gmail.com wrote:
HI all.
I've got working samba AD server. It is playing nicely with Windows 10 and also successfully authenticating Linux machines with SSSD. On the Windows machines I have our EMC storage smb mounted via group policy. Managing permissions for users and groups there, as you know, happens with right click, security etc..
As you may have already guessed the troubles come when my Linux machines, that access the storage via nfs mount
NFSv3, or NFSv4?
need to work with folders and files created from the Windows PCs. Linux doesn't "see" the actual user/group that owns given folder. It interprets it into ID numbers starting from 1000. I'm quite sure that this is common and known issue, but I don't know what is the right way to deal with it, so any wisdom will be helpful.
Here's smb.conf from server
[global]
netbios name = AD realm = XXXXXX server role = active directory domain controller server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate workgroup = XXXX idmap config XXXX:unix_nss_info = yes
Your "idmap config" setting implies that you are setting full RFC2307 attributes (uidNumber, gidNumber, homeDirectory, loginShell, et. al.) in LDAP.
If that is correct, then your sssd.conf ldap_id_mapping setting:
log file = /var/log/samba/samba.log log level = 3
[netlogon] path = /usr/local/samba/var/locks/sysvol/XXXXXX/scripts read only = No [sysvol] path = /usr/local/samba/var/locks/sysvol read only = No
also, sssd.conf from client
[sssd]
domains = xxxx config_file_version = 2 services = nss, pam
[domain/xxxx]
ad_domain = xxxx krb5_realm = XXXX 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
…is wrong. This must be False, so that sssd uses the RFC2307 attributes, instead of auto-generating uid/gid values based on the SID/RID attributes. See the "ID MAPPING" section of sssd-ldap(5).
use_fully_qualified_names = False fallback_homedir = /home/%u access_provider = ad
and nsswitch.conf
passwd: files sss shadow: files sss group: files sss
Will appreciate any wisdom.
You need to be consistent about how uid/gid information is derived from LDAP.
Either set full RFC2307 attributes and use them, or configure ID mapping. But whichever path you choose, you must implement it consistently. (You can have sssd mimic winbind's idmap_autorid algorithm if necessary; see the ldap_idmap_autorid_compat setting.)
Also note that once you go down either path, you're pretty much stuck with that decision, because changing the mechanism would invalidate all existing uids/gids.
You are absolutely right and that's why I want to fix all of this while I only have very few users. The OneFS Isilon storage has both NFS3 and NFS4 enabled, but I'm using v3.
The samba AD smb.conf file was generated through the samba provisioning tool so I guess that some manual tweaking will be needed. Obviously I'm very new to SSSD, so I'm not sure which way is better - sticking to RFC2307 or there is better option for my particular needs? I guess that is what you mean with " ldap_idmap_autorid_compat"? Adding manually uidNumber, gidNumber etc. is something I'd like to avoid if possible.
On Tue, May 1, 2018 at 10:24 PM, James Ralston ralston@pobox.com wrote:
On Mon, Apr 30, 2018 at 8:35 AM, Zdravko Zdravkov nirayah@gmail.com wrote:
HI all.
I've got working samba AD server. It is playing nicely with Windows 10 and also successfully authenticating Linux machines with SSSD. On the Windows machines I have our EMC storage smb mounted via group policy. Managing permissions for users and groups there, as you know, happens with right click, security etc..
As you may have already guessed the troubles come when my Linux machines, that access the storage via nfs mount
NFSv3, or NFSv4?
need to work with folders and files created from the Windows PCs. Linux doesn't "see" the actual user/group that owns given folder. It interprets it into ID numbers starting from 1000. I'm quite sure that this is common and known issue, but I don't know what is the right way to deal with it, so any wisdom will be helpful.
Here's smb.conf from server
[global]
netbios name = AD realm = XXXXXX server role = active directory domain controller server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc,
drepl, winbindd, ntp_signd, kcc, dnsupdate
workgroup = XXXX idmap config XXXX:unix_nss_info = yes
Your "idmap config" setting implies that you are setting full RFC2307 attributes (uidNumber, gidNumber, homeDirectory, loginShell, et. al.) in LDAP.
If that is correct, then your sssd.conf ldap_id_mapping setting:
log file = /var/log/samba/samba.log log level = 3
[netlogon] path = /usr/local/samba/var/locks/sysvol/XXXXXX/scripts read only = No [sysvol] path = /usr/local/samba/var/locks/sysvol read only = No
also, sssd.conf from client
[sssd]
domains = xxxx config_file_version = 2 services = nss, pam
[domain/xxxx]
ad_domain = xxxx krb5_realm = XXXX 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
…is wrong. This must be False, so that sssd uses the RFC2307 attributes, instead of auto-generating uid/gid values based on the SID/RID attributes. See the "ID MAPPING" section of sssd-ldap(5).
use_fully_qualified_names = False fallback_homedir = /home/%u access_provider = ad
and nsswitch.conf
passwd: files sss shadow: files sss group: files sss
Will appreciate any wisdom.
You need to be consistent about how uid/gid information is derived from LDAP.
Either set full RFC2307 attributes and use them, or configure ID mapping. But whichever path you choose, you must implement it consistently. (You can have sssd mimic winbind's idmap_autorid algorithm if necessary; see the ldap_idmap_autorid_compat setting.)
Also note that once you go down either path, you're pretty much stuck with that decision, because changing the mechanism would invalidate all existing uids/gids. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org