Bivans, Crispin
2020-Jun-04 17:52 UTC
[Samba] Unable to map AD Users to existing local Unix users since 4.8.x
Statement of issue -------------------------- A feature our company relied on to map AD users to existing Unix users was broken when upgrading to 4.8.x Samba packages from Red Hat for RHEL7.6 History of prior usage -------------------------- For over 5+ years and many more, our company would configure for server mode = ADS with net ads join and allow Samba to map incoming users by user name to existing Unix users. The resulting login would acquire the Unix user's primary and secondary groups for any underlying file operations. Every user got the same UID on all systems because of our user management practices. We did not need anything from Windows team except to join new systems. All was great. Version changes ------------------------- With the upgrade to Samba 4.8.x as delivered by Red Hat RHEL7.6, all that is broken and remains broken in 4.9.x. Any server with the upgrade could not do basic functionality and prompted us for username/password. It took a long time to fight it back to 'working kinda'. Countless hours and cases spent with Red Hat support. Red Hat's attempts to get us 'current' -------------------------------------- Red Hat support stated we were on an unsupported configuration and needed to implement Winbind. This resulted in a host of unexpected side-effects, namely that we still can't get AD users to map to existing Unix users. Home directory shares no longer work. Files are created that look like a proper matching username but are actually a totally different owner ID in disguise. Primary groups of users are always set to Domain Users. File permission issues when looking at the OS side. Countless hours trying to get resolution through Red Hat. Workarounds we've done --------------------------------- To mimic the primary groups on each server we've used "force group" setting to make a specific unix group the default. This allows new files to take on the correct group assuming that is the only group needed for the share. This isn't always possible on every share we have due to how rights are setup. Home directory shares are disabled. Fortunately few users need it but it would be nice to use it. Why are the Red Hat support recommendations to use Winbind a problem? ------------------------------------- We have millions of files with already assigned Unix users and groups. There would be a lot work to make it match the Winbind style by re-owning files to the Windows UIDs (280+ servers). And the Windows team separately would have to be convinced to create and maintain special groups just for our purposes for a potential audience of 600 users and 30+ groups. More coordination since we don't have Admin privileges over there. We've looked at some AD related settings to set primary group but the common problem those methods have is that every server may have a different 'preferred group' for the system users. If that user exists on multiple servers then there would be no happy one-size fits all primary group. Oracle servers may have one preferred group for users and Informatica servers will have another, as an example. Home directory shares remain unusable due to the UID not coming in correctly. What can we do about it? ---------------------------------- Is there a set of settings to restore the mapping of AD users to pre-existing Unix Users? Does the official Samba distributed project source continue to support AD Users mapping to pre-existing Unix Users? Do we just need to compile our own Samba to get back that functionality? Sample configuration for a server pre-Samba 4.8.x that mapped users correctly to local unix: ---------------------------------- [global] workgroup = USVCI001 server string = Samba Server name security = ADS realm = USVCI001.VCI.NA.VWG kerberos method = secrets and keytab log file = /var/log/samba/%m.log max log size = 1000 load printers = No local master = No domain master = No read only = No printing = bsd printcap name = /dev/null wide links = no <End of this config> Sample configuration for a server after attempting to make it kinda work on 4.8 and 4.9: ---------------------------------- [global] server string = A Server name security = ADS workgroup = USVCI001 realm = USVCI001.VCI.NA.VWG idmap config * : backend = autorid idmap config * : range = 100000-19999999 idmap config * : rangesize = 1000000 template shell = /sbin/nologin winbind use default domain = yes kerberos method = secrets and keytab client min protocol = SMB2 server min protocol = SMB2 client NTLMv2 auth = yes client lanman auth = no lanman auth = no ntlm auth = no load printers = No printing = bsd printcap name = /dev/null log file = /var/log/samba/samba~%m~%I~%U~%i.log loglevel = 3 auth_audit:3 max log size = 10000 <End of this config>
Rowland penny
2020-Jun-04 18:29 UTC
[Samba] Unable to map AD Users to existing local Unix users since 4.8.x
On 04/06/2020 18:52, Bivans, Crispin via samba wrote:> Statement of issue > > -------------------------- > > A feature our company relied on to map AD users to existing Unix users was broken when upgrading to 4.8.x Samba packages from Red Hat for RHEL7.6 > > > > History of prior usage > > -------------------------- > > For over 5+ years and many more, our company would configure for server mode = ADS with net ads join and allow Samba to map incoming users by user name to existing Unix users. The resulting login would acquire the Unix user's primary and secondary groups for any underlying file operations. Every user got the same UID on all systems because of our user management practices. We did not need anything from Windows team except to join new systems. > > All was great.No, you just thought it was :-> Version changes > > ------------------------- > > With the upgrade to Samba 4.8.x as delivered by Red Hat RHEL7.6, all that is broken and remains broken in 4.9.x.It was actually delivered by Samba and, as far as you are concerned, it is still 'broken' in 4.10.x, 4.11.x and 4.12.x> Any server with the upgrade could not do basic functionality and prompted us for username/password. It took a long time to fight it back to 'working kinda'. Countless hours and cases spent with Red Hat support. > > > > Red Hat's attempts to get us 'current' > > -------------------------------------- > > Red Hat support stated we were on an unsupported configuration and needed to implement Winbind. This resulted in a host of unexpected side-effects, namely that we still can't get AD users to map to existing Unix users. Home directory shares no longer work. Files are created that look like a proper matching username but are actually a totally different owner ID in disguise. Primary groups of users are always set to Domain Users. File permission issues when looking at the OS side. Countless hours trying to get resolution through Red Hat.Your configuration is unsupported by Samba and probably always has been.> Workarounds we've done > > --------------------------------- > > To mimic the primary groups on each server we've used "force group" setting to make a specific unix group the default. This allows new files to take on the correct group assuming that is the only group needed for the share. > > This isn't always possible on every share we have due to how rights are setup. > > Home directory shares are disabled. Fortunately few users need it but it would be nice to use it.There are at least a couple of ways of doing this, set a 'template homedir' line in smb.conf (though this would affect every user), or set the 'unixHomeDirectory' attribute in the users AD object.> Why are the Red Hat support recommendations to use Winbind a problem?No, the problem is your old unsupported way of doing things, even 5 years ago, you could have done it correctly.> ------------------------------------- > > We have millions of files with already assigned Unix users and groups. There would be a lot work to make it match the Winbind style by re-owning files to the Windows UIDs (280+ servers). And the Windows team separately would have to be convinced to create and maintain special groups just for our purposes for a potential audience of 600 users and 30+ groups. More coordination since we don't have Admin privileges over there. > > We've looked at some AD related settings to set primary group but the common problem those methods have is that every server may have a different 'preferred group' for the system users. If that user exists on multiple servers then there would be no happy one-size fits all primary group. Oracle servers may have one preferred group for users and Informatica servers will have another, as an example.You do have problems, I think your only way out of this is to create all your users and groups in AD. Now it sounds like your AD team aren't enamoured about doing this, so have you considered setting up your own AD domain using Samba.> Home directory shares remain unusable due to the UID not coming in correctly. > > What can we do about it? > > ---------------------------------- > > Is there a set of settings to restore the mapping of AD users to pre-existing Unix Users?No> > Does the official Samba distributed project source continue to support AD Users mapping to pre-existing Unix Users?I do not think it ever did.> Do we just need to compile our own Samba to get back that functionality?How ? the functionality that let your system work has been removed. Rowland
Maybe Matching Threads
- Unable to map AD Users to existing local Unix users since 4.8.x
- Unable to map AD Users to existing local Unix users since 4.8.x
- Unable to map AD Users to existing local Unix users since 4.8.x
- please confirm: sssd not a good idea :)
- RHEL7/Centos7 with Samba AD