OK for the DC. I noticed that converting users and groups to sid with the example below seems to work fine: # wbinfo -n DOMAIN\\user S-1-5-21-948789634-15155995-928725530-6864 SID_USER (1) # wbinfo -n DOMAIN\\group S-1-5-21-948789634-15155995-928725530-11178 SID_DOM_GROUP (2) However, applications using PAM and winbind seem to fail when trying to convert to sid. For instance, just to name one, openvpn is failing with messages such as: AUTH-PAM: BACKGROUND: my_conv[0] query='Cannot convert group GROUP to sid, please contact your administrator to see if group GROUP is valid.' style=4 I know this is the samba ML, but I just want to share part of the openvpn config to see if my misconfiguration is here or there. openvpn uses: plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn-ivpn My pam.d config is: # cat /etc/pam.d/openvpn-ivpn #%PAM-1.0 # $Id$ auth required pam_env.so auth sufficient pam_winbind.so require_membership_of=GROUP auth sufficient pam_unix.so likeauth nullok use_first_pass auth required pam_deny.so account sufficient pam_winbind.so require_membership_of=GROUP account required pam_unix.so password required pam_cracklib.so retry=3 password sufficient pam_unix.so nullok use_authtok md5 shadow password required pam_deny.so session required pam_mkhomedir.so skel=/etc/skel/ umask=0077 session required pam_limits.so session required pam_unix.so And this is my smb.conf: [global] workgroup = DOMAIN security = ADS realm = DOMAIN.ORG winbind refresh tickets = Yes vfs objects = acl_xattr map acl inherit = Yes store dos attributes = Yes dedicated keytab file = /etc/krb5.keytab kerberos method = secrets and keytab winbind use default domain = yes ; remove when in production: winbind enum users = yes winbind enum groups = yes load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes log file = /var/log/samba/%m.log log level = 1 idmap config * : backend = tdb idmap config * : range = 3000-7999 idmap config DOMAIN : backend = rid idmap config DOMAIN : range = 10000-999999 idmap config SSIB.ES : backend = rid idmap config SSIB.ES : range = 1000000-9999999 template shell = /bin/bash template homedir = /home/%U server string = Samba2 ; encrypt passwords = yes unix password sync = Yes pam password change = yes obey pam restrictions = yes dos charset = 850 unix charset = ISO8859-1 What can I try? Regards, Vieri
On 15/06/2020 17:13, Vieri Di Paola via samba wrote:> OK for the DC. >You have: winbind use default domain = yes And: idmap config DOMAIN : backend = rid idmap config DOMAIN : range = 10000-999999 idmap config SSIB.ES : backend = rid idmap config SSIB.ES : range = 1000000-9999999 You cannot use both, remove either 'winbind use default domain = yes' or the last two 'idmap config' lines (SSIB.ES looks like a kerberos realm anyway) You also have 'unix password sync = Yes', you should remove this, you cannot have users in /etc/passwd and AD. Rowland
On 6/15/20 11:29 AM, Rowland penny via samba wrote: ... snippity> You also have 'unix password sync = Yes', you should remove this, you cannot > have users in /etc/passwd and AD.Actually, as far as a base statement, you can have both, that is, the idea of a username in Windows AD and the same username in /etc/passwd. The namespaces are not cojoined. However, that doesn't mean "unix password sync" is ok. I don't know enough about the assumptions being made inside of samba with regards to that. Note, having the same username in the two namespaces can cause some ambiguity. As simply reporting a username doesn't identify the namespace from which it came from. You'd have to look (for example) at the underlying uid. Especially true where default domain is used. While this might appear to be "incorrect", it could also be looked at as a feature. And something that has been *ix for a long time really. In other words, things can be based on context. It might be a mistake to limit/control either namespace by trying to force there to just be one.