Hide Forgot
Created attachment 1143388 [details] smb.conf file Description of problem: This may not be a bug or may not be a bug it just maybe that I don't understand the configuration I need to make "sssd-libwbclient" work. Maybe the bug would then be lack of documentation? It's my understanding that if using SSSD joined machine to AD you should have to use Winbind anymore but can use sssd-libwbclient to do SID<->UID mapping. All I should have to do is run: # alternatives --set libwbclient.so.0.12-64 /usr/lib64/sssd/modules/libwbclient.so.0.12.0 Verify with # alternatives --display libwbclient.so.0.12-64 libwbclient.so.0.12-64 - status is manual. link currently points to /usr/lib64/sssd/modules/libwbclient.so.0.12.0 Then you don't need anything specifically in smb.conf for mapping or do you still need to specify winbind options? I have attached my smb.conf. When I go to the properties of a directory in the test share on this machine from Windows and select the security tab, I just see the SID's and not the names of the domain users. Though these SID's seem to be valid entries for the directory. Also if I add permission entries from Windows it works when I add new entries by name using domain accounts. These successfully add and the permissions get added correctly to the directory but if I reopen the dialog, these new entries are just SID's as well as the existing ones. Version-Release number of selected component (if applicable): sssd-libwbclient-1.13.3-6.fc23.x86_64 sssd-1.13.3-6.fc23.x86_64 How reproducible: Everytime Steps to Reproduce: 1. Have an AD joined SSSD machine. 2. Switch Samba to use ssd-libwbclient for SID mapping by running alternatives --set libwbclient.so.0.12-64 /usr/lib64/sssd/modules/libwbclient.so.0.12.0 3. Browse to a share and select properties and the security tab Actual results: Displays items as SIDs Expected results: Should translate these SIDs to Domain Users and Groups Additional info:
Can you attach your sssd.conf as well.
Created attachment 1143390 [details] sssd.conf
Please try if setting 'use_fully_qualified_names = True' already helps. You must remove the cache file /var/lib/sss/db/cache_* with rm after changing the option and restart SSSD.. Fully qualified names are currently a requirement for sssd-libwbclient.
That does help a lot. But personally we use "use_fully_qualified_names = False" in our environment. Will this be supportable in the future with this? But even with "use_fully_qualified_names = True", entries look a little unusual from Windows compared to other Samba or Windows servers. A typical entry looks like: csimpson (ukiongeo.com\csimpson) software (ukiongeo.com\software) , whereas a similar entry to a Samba/Winbind or Windows system would shows the entries as: Colin Simpson (Colin.Simpson) software (UKION\software) So it looks like for the users real name you are using sAMAccountName when you should maybe be using "displayName" or "cn" not sure which. Secondly, I did see a bug report saying you don't do UPN names yet, but even with the "software" group (which doesn't have have UPN not sure groups can even) it should be displayed as "UKION\software". And probably my user account should be displayed as "UKION\csimpson" in the absence of UPN support or if it isn't present for this user.
(In reply to Colin Simpson from comment #4) > That does help a lot. But personally we use "use_fully_qualified_names = > False" in our environment. Will this be supportable in the future with this? > > But even with "use_fully_qualified_names = True", entries look a little > unusual from Windows compared to other Samba or Windows servers. > > A typical entry looks like: > > > csimpson (ukiongeo.com\csimpson) > software (ukiongeo.com\software) > > , whereas a similar entry to a Samba/Winbind or Windows system would shows > the entries as: > > Colin Simpson (Colin.Simpson) ^^^^^^^^^^^^^^^^^^^^^^^^ If you do not like email-like output then you can change default full_name_format. More details in man sssd.conf I didn't test but following should work "%3$s\\%1$s" > software (UKION\software) > > So it looks like for the users real name you are using sAMAccountName when > you should maybe be using "displayName" or "cn" not sure which. > sssd uses by default attribute "sAMAccountName". If you want to change it you set attribute ldap_user_name to whatever will work for you. BTW we recently changed default attribute for group to "sAMAccountName". You might change ldap_group_name as well @see related pages: https://msdn.microsoft.com/en-us/library/ms679635%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/ms678697%28v=vs.85%29.aspx https://fedorahosted.org/sssd/ticket/2593
I'm happy with the usernames/groupnames as presented to Unix from SSSD (in our case the sAMAccountName flat with no domain component and not using the UPN name). And you seem to be suggesting I can change the output of this Windows dialog by changing sssd.conf (which will change the Unix presentation of this data to nss), I'm suggesting this is possibly the wrong approach to the output of this dialog. As in shouldn't the output of this permissions dialog not be standard (as Windows does and Samba/Winbind presents) ? And like Winbind this should be independent of how this data is presented to the Linux nss system? It looks to me like this dialog is usually (to Windows or Samba Winbind servers): For Groups something like: name (DOMAIN(pre 2000 i.e. not fully qualified)\sAMAccountName) And Users something like: displayName (userPrincipalName) This is an educated guess, not sure what the standard says. But I'm suggesting that what is being done here currently isn't standard? And certainly looks different to other systems when viewed from Windows. I'm further suggesting that this output should be independent of what the Linux nss system sees from sssd? But I've not checked the standard..... I was aware the group attribute had changed to sAMAccountName, I was the trouble maker on that one too that suggested it should be changed :-)
You are right, currently sssd-winbind uses the same data as the nss system. My plan is to improve this in a way that the output format can be configured independently but I can currently not give an estimate when this will be done. We currently working on improving the internal representation of the cached data (https://fedorahosted.org/sssd/wiki/DesignDocs/SysdbFullyQualifiedNames). When this is done I would like to start improving and enhancing sssd-winbind.
Sounds good, happy to wait until the materialises. As I say, I also suggest you review the defaults to make the output look like Windows or Samba/Winbind (i.e Standard). I guess this bug can close until then.
By the way, the sysdb refactoring Sumit mentioned should also allow you to set the output of a user lookups from a trusted domain to username only (IIRC you wanted that RFE as well some time ago..)
(In reply to Colin Simpson from comment #8) > Sounds good, happy to wait until the materialises. As I say, I also suggest > you review the defaults to make the output look like Windows or > Samba/Winbind (i.e Standard). > > I guess this bug can close until then. Or we can move this ticket to rawhide. So it will be clear that we plan to do this but it's not clear when it will be fixed.
I would prefer to keep the bug open as well.
I changed the summary a bit and moved the ticket to rawhide. I hope everyone agrees.
(In reply to Jakub Hrozek from comment #9) > By the way, the sysdb refactoring Sumit mentioned should also allow you to > set the output of a user lookups from a trusted domain to username only > (IIRC you wanted that RFE as well some time ago..) Sounds good!
Summit, Do we need to clone this BZ to upstream?
Hi Lukas, yes, please do. I think then this ticket can be even closed as CLOSED-UPSTREAM.
Upstream ticket: https://fedorahosted.org/sssd/ticket/3221
As this is an RFE that we've been already tracking in our pagure I'm closing this bug as "UPSTREAM". For more details, please, feel free to follow: https://pagure.io/SSSD/sssd/issue/3221 If, for some reason, there's the need to re-open this bug, feel free to do so.