It wasn't obvious from the documentation whether with sssd-libwbclient (only, ie without sssd-winbind-idmap installed and configured in smb.conf, since sssd-winbind-idmap is not available in most versions of RHEL7 as it was only recently added),
Samba's uid_to_sid(function) can always do the lookup uid_to_sid to AD if using winbind but it wasn't clear whether this would work with sssd-libwbclient (only) installed and what additional Samba configuration is needed for that.
Without this the owner of a file (viewed from the WIndows client) from Explorer GUI looks like "Unix user\10000" rather than "user@domain" (as it would for Windows to Windows, or if Winbind were running on the Samba server joined to AD)
On Wed, Jan 25, 2017 at 10:54:17PM -0000, smfrench@gmail.com wrote:
It wasn't obvious from the documentation whether with sssd-libwbclient (only, ie without sssd-winbind-idmap installed and configured in smb.conf, since sssd-winbind-idmap is not available in most versions of RHEL7 as it was only recently added),
Samba's uid_to_sid(function) can always do the lookup uid_to_sid to AD if using winbind but it wasn't clear whether this would work with sssd-libwbclient (only) installed and what additional Samba configuration is needed for that.
It is sufficient in install sssd-libwbclient and make sure it is used instead of Samba's libwbclient, use the alternatives command to check this.
No additional Samba configuration is needed but there are certain restrictions you should be aware of. Only Kerberos authentication is support since SSSD cannot handle NTLM. Additionally SSSD must be configured to return fully-qualified user and group names ('use_fully_qualified_names = True') to make sssd-libwbclient work as expected. The option will be set by default if you join the AD domain with realmd.
HTH
bye, Sumit
Without this the owner of a file (viewed from the WIndows client) from Explorer GUI looks like "Unix user\10000" rather than "user@domain" (as it would for Windows to Windows, or if Winbind were running on the Samba server joined to AD) _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Thu, 2017-01-26 at 09:35 +0100, Sumit Bose wrote:
On Wed, Jan 25, 2017 at 10:54:17PM -0000, smfrench@gmail.com wrote:
It wasn't obvious from the documentation whether with sssd-libwbclient (only, ie without sssd-winbind-idmap installed and configured in smb.conf, since sssd-winbind-idmap is not available in most versions of RHEL7 as it was only recently added),
Samba's uid_to_sid(function) can always do the lookup uid_to_sid to AD if using winbind but it wasn't clear whether this would work with sssd-libwbclient (only) installed and what additional Samba configuration is needed for that.
It is sufficient in install sssd-libwbclient and make sure it is used instead of Samba's libwbclient, use the alternatives command to check this.
No additional Samba configuration is needed but there are certain restrictions you should be aware of. Only Kerberos authentication is support since SSSD cannot handle NTLM. Additionally SSSD must be configured to return fully-qualified user and group names ('use_fully_qualified_names = True') to make
"use_fully_qualified_names = true" forces user@domain.com as login name(and my NetworkManager got some problem, needs debugging though).
Why is "use_fully_qualified_names = true" required for sssd-libwbclient? We use it without "use_fully_qualified_names = true" already so am not sure why it is need.
sssd-libwbclient work as expected. The option will be set by default if you join the AD domain with realmd.
HTH
bye, Sumit
On Wed, Jan 25, 2017 at 10:54:17PM -0000, smfrench(a)gmail.com wrote:
It is sufficient in install sssd-libwbclient and make sure it is used instead of Samba's libwbclient, use the alternatives command to check this.
I applied this hint on Arch Linux running smbd version 4.5.2 and and sssd 1.14.2. Users are now correctly displayed (user@domain). The real drawback as for many other distributions is, that each time libwbclient is updated, we have to manually fix the library links.
But there is an even worse issue, when using sssd instead of winbind on a Samba domain server. Samba (smbd) stores ACLs of its shares in a database (share_info.tdb). In the example below you see the content of a test share 'fixedtest' (fixed as we applied Sumit's hint). REVISION:1 CONTROL:SR|DI|DP OWNER:Unix User\root GROUP:Unix Group\root ACL:Unix Group\domain admins@samdom.com:ALLOWED/OI|CI|I/FULL ACL:Everyone:ALLOWED/OI|CI|I/READ ACL:Unix User\root:ALLOWED/I/FULL ACL:Creator Owner:ALLOWED/OI|CI|IO|I/FULL ACL:Unix Group\root:ALLOWED/I/FULL ACL:Creator Group:ALLOWED/OI|CI|IO|I/FULL
On a Windows 7 client, the permissions look like this: Path : Microsoft.PowerShell.Core\FileSystem::\server01\adminshare\fixedtest Owner : O:S-1-22-1-0 Group : G:S-1-22-2-0 Access : S-1-22-2-512 Allow FullControl Everyone Allow ReadAndExecute, Synchronize S-1-22-1-0 Allow FullControl CREATOR OWNER Allow FullControl S-1-22-2-0 Allow FullControl CREATOR GROUP Allow FullControl The GUI displays the SIDs as domain admins@samdom.com (Unix Group\domain admins@samdom.com) and root (Unix User\root). The domain administrator, who created the folder is mapped to root by a smbd user map.
With these ACLs other users, that belong to group 'Domain Admins' have full access to this folder. However, when we replace from a Windows 7 client the above ACL by the following one: Path : Microsoft.PowerShell.Core\FileSystem::\server01\adminshare\fixedtest Owner : O:S-1-22-1-0 Group : G:S-1-22-2-0 Access : SAMDOM\Domain Admins Allow FullControl SAMDOM\Domain Users Allow ReadAndExecute, Synchronize SAMDOM\Department Allow Modify, Synchronize
only the domain administrator has still access. All other users, that belong to the Domain Admins group get access denied.
The resulting Samba share database has following ACL: REVISION:1 CONTROL:SR|PD|SI|DI|DP OWNER:Unix User\root GROUP:Unix Group\root ACL:S-1-5-21-1961322486-2366424275-2351687912-512:ALLOWED/OI|CI/FULL ACL:S-1-5-21-1961322486-2366424275-2351687912-513:ALLOWED/OI|CI/READ ACL:S-1-5-21-1961322486-2366424275-2351687912-1116:ALLOWED/OI|CI/CHANGE
and getfacl on server01 shows: # file: fixedtest # owner: root # group: root user::rwx user:root:rwx group::rwx group:root:rwx group:domain\040admins@samdom.com:rwx mask::rwx other::r-x default:user::rwx default:user:root:rwx default:group::rwx default:group:root:rwx default:group:domain\040admins@samdom.com:rwx default:mask::rwx default:other::r-x
For us it looks like that if smbd uses libwbclient provided by sssd the domain is ow correctly added, but smbd is not able to correctly map SIDs to domain groups or users to store in its share ACL DB.
What's still wrong here?
Btw. getent group domain\ admins correctly prints domain admins@samdom.com:*:512:administrator@samdom.com,admin2@samdom.com
On Fri, Jan 27, 2017 at 11:15:40AM -0000, rdratlos@yahoo.co.uk wrote:
On Wed, Jan 25, 2017 at 10:54:17PM -0000, smfrench(a)gmail.com wrote:
It is sufficient in install sssd-libwbclient and make sure it is used instead of Samba's libwbclient, use the alternatives command to check this.
I applied this hint on Arch Linux running smbd version 4.5.2 and and sssd 1.14.2. Users are now correctly displayed (user@domain). The real drawback as for many other distributions is, that each time libwbclient is updated, we have to manually fix the library links.
Yes it is unfortunate that libwbclient is a real library and a configurable plugin. In Fedora the alternatives tool is used to manage this which works but is imo not an elegant solution.
Btw, please note that in the log run might be necessary to run winbind and use Samba's libwbclient due to limitations in SSSD and increased security level in AD. E.g. only winbind can manage the Secure Channel connection to a AD DC. To make sure winbind and SSSD will use the same ID-SID mapping we added an idmap plugin for winbind which will ask SSSD for the mapping, see man idmap_sss for details.
But there is an even worse issue, when using sssd instead of winbind on a Samba domain server. Samba (smbd) stores ACLs of its shares in a database (share_info.tdb). In the example below you see the content of a test share 'fixedtest' (fixed as we applied Sumit's hint). REVISION:1 CONTROL:SR|DI|DP OWNER:Unix User\root GROUP:Unix Group\root ACL:Unix Group\domain admins@samdom.com:ALLOWED/OI|CI|I/FULL ACL:Everyone:ALLOWED/OI|CI|I/READ ACL:Unix User\root:ALLOWED/I/FULL ACL:Creator Owner:ALLOWED/OI|CI|IO|I/FULL ACL:Unix Group\root:ALLOWED/I/FULL ACL:Creator Group:ALLOWED/OI|CI|IO|I/FULL
On a Windows 7 client, the permissions look like this: Path : Microsoft.PowerShell.Core\FileSystem::\server01\adminshare\fixedtest Owner : O:S-1-22-1-0 Group : G:S-1-22-2-0 Access : S-1-22-2-512 Allow FullControl Everyone Allow ReadAndExecute, Synchronize S-1-22-1-0 Allow FullControl CREATOR OWNER Allow FullControl S-1-22-2-0 Allow FullControl CREATOR GROUP Allow FullControl The GUI displays the SIDs as domain admins@samdom.com (Unix Group\domain admins@samdom.com) and root (Unix User\root). The domain administrator, who created the folder is mapped to root by a smbd user map.
With these ACLs other users, that belong to group 'Domain Admins' have full access to this folder. However, when we replace from a Windows 7 client the above ACL by the following one: Path : Microsoft.PowerShell.Core\FileSystem::\server01\adminshare\fixedtest Owner : O:S-1-22-1-0 Group : G:S-1-22-2-0 Access : SAMDOM\Domain Admins Allow FullControl SAMDOM\Domain Users Allow ReadAndExecute, Synchronize SAMDOM\Department Allow Modify, Synchronize
only the domain administrator has still access. All other users, that belong to the Domain Admins group get access denied.
The resulting Samba share database has following ACL: REVISION:1 CONTROL:SR|PD|SI|DI|DP OWNER:Unix User\root GROUP:Unix Group\root ACL:S-1-5-21-1961322486-2366424275-2351687912-512:ALLOWED/OI|CI/FULL ACL:S-1-5-21-1961322486-2366424275-2351687912-513:ALLOWED/OI|CI/READ ACL:S-1-5-21-1961322486-2366424275-2351687912-1116:ALLOWED/OI|CI/CHANGE
and getfacl on server01 shows: # file: fixedtest # owner: root # group: root user::rwx user:root:rwx group::rwx group:root:rwx group:domain\040admins@samdom.com:rwx mask::rwx other::r-x default:user::rwx default:user:root:rwx default:group::rwx default:group:root:rwx default:group:domain\040admins@samdom.com:rwx default:mask::rwx default:other::r-x
For us it looks like that if smbd uses libwbclient provided by sssd the domain is ow correctly added, but smbd is not able to correctly map SIDs to domain groups or users to store in its share ACL DB.
What's still wrong here?
I think you have to inspect the Samba logs to see why some ACLs get lost and why access is denied. While reading your description my first idea was https://fedorahosted.org/sssd/ticket/3028 but this is already fixed in sssd-1.14.2.
bye, Sumit
Btw. getent group domain\ admins correctly prints domain admins@samdom.com:*:512:administrator@samdom.com,admin2@samdom.com _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Dear Sumit,
thank you for your quick reply and the good hints.
Access works now as expected. The reason of the failure was one wrong libwbclient link. Admins have to really be carefully, when switching to sssd's libwbclient.so.
In parallel, I also switched the member server to Samba's winbind to compare the outputs, as even up to level 10 there was no useful information in the smbd logs. Interestingly the output of smbcacl is now (with winbind): REVISION:1 CONTROL:SR|PD|SI|DI|DP OWNER:Unix User\root GROUP:Unix Group\root ACL:SAMDOM\Domain Admins:ALLOWED/OI|CI/FULL ACL:SAMDOM\Domain Users:ALLOWED/OI|CI/READ ACL:SAMDOM\Department:ALLOWED/OI|CI/CHANGE
smbcacl seems to require winbind to translate SIDs into uids/guids. On the other hand getent group domain\ admins now prints: domain admins@samdom.com:*:512. I. e. on the linux side the group member information gets lost when using winbind.
From a long samba list discussion I have got the impression, that it's more a philosophy question, if to use sssd or winbind on a domain member server. Do you still agree? Or what is your recommendation especially, when taking your long term statement above into account.
Best regards
Thomas
On Fri, Jan 27, 2017 at 05:46:11PM -0000, rdratlos@yahoo.co.uk wrote:
Dear Sumit,
thank you for your quick reply and the good hints.
Access works now as expected. The reason of the failure was one wrong libwbclient link. Admins have to really be carefully, when switching to sssd's libwbclient.so.
In parallel, I also switched the member server to Samba's winbind to compare the outputs, as even up to level 10 there was no useful information in the smbd logs. Interestingly the output of smbcacl is now (with winbind): REVISION:1 CONTROL:SR|PD|SI|DI|DP OWNER:Unix User\root GROUP:Unix Group\root ACL:SAMDOM\Domain Admins:ALLOWED/OI|CI/FULL ACL:SAMDOM\Domain Users:ALLOWED/OI|CI/READ ACL:SAMDOM\Department:ALLOWED/OI|CI/CHANGE
smbcacl seems to require winbind to translate SIDs into uids/guids.
I have to check how smbcacl does the lookup for the mapping, currently I have no idea why it does only work with winbind.
On the other hand getent group domain\ admins now prints: domain admins@samdom.com:*:512. I. e. on the linux side the group member information gets lost when using winbind.
'domain users' is special because it is typically the primary group of the AD users. But iirc there are also smb.conf options to control the listing of group members, see e.g. winbind expand groups.
From a long samba list discussion I have got the impression, that it's more a philosophy question, if to use sssd or winbind on a domain member server. Do you still agree? Or what is your recommendation especially, when taking your long term statement above into account.
It might be a philosophical question for a general domain member but not when running Samba on the domain member. Since there are a number of limitations in SSSD's implementation of libwbclient it is more a question of the use-case. E.g if it is ok to restrict authentication to the Samba fileserver to Kerberos, which in general implies that the fully-qualified DNS name of the Samba server has to be used to access the service then SSSD's libwbclient might work for you. If you need NTLM because you want to use IP addresses of short names to access the fileserver you have to use winbind.
bye, Sumit
Best regards
Thomas _______________________________________________ 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