Ugh, I knew I forgot something. Here is smb.conf: --- [global] kerberos method = system keytab template homedir = /soe/%U workgroup = BSOE template shell = /bin/bash security = ads realm = AD.SOE.UCSC.EDU idmap config BSOE : schema_mode = rfc2307 idmap config BSOE : range = 100-999999 idmap config BSOE : backend = ad idmap config BSOE : unix_nss_info = yes idmap config BSOE : unix_primary_group = yes idmap config * : range = 10000000-10999999 idmap config * : backend = tdb winbind use default domain = no winbind refresh tickets = yes winbind offline logon = yes winbind enum groups = no winbind enum users = no ################################################################################ # You should not define any shares in this file directly, use shares.conf. # ################################################################################ include = /etc/samba/shares.conf --- Here's an example of one of the share configurations from shares.conf, which are uniform: --- [backups] path = /notbackedup/backups comment = Window Servers Backups create mask = 0640 directory mask = 0750 force create mode = 0640 force directory mode = 0750 force group = backups valid users = +BSOE\backups-group +backups On Tue, Jul 9, 2019 at 10:59 AM Rowland penny via samba < samba at lists.samba.org> wrote:> On 09/07/2019 18:38, Eric Shell via samba wrote: > > I am setting up a CentOS 7 system as a file server within an AD domain, > > following the following Red Hat documentation: > > > > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-file_and_print_servers > > > > Here is some information that likely complicates things: > > > > - we have a number of users and groups with sub-1000 uid or gid numbers > > which can't easily be addressed > > - the system is integrated into a OpenLDAP service but UNIX attributes > are > > replicated to AD from OpenLDAP so uid and gid values match across all > users > > and groups > > - the system's samba shares are themselves NFS-mounted from a ZFS file > > server > > > > > -------------------------------------------------------------------------------- > > > > Thus far I've done the following: > > > > 1. installed packages - realmd oddjob-mkhomedir oddjob > > samba-winbind-clients samba-winbind samba-common-tools samba > > samba-winbind-krb5-locator > > 2. joined the AD domain with "realm join" and the > --automatic-id-mapping=no > > option, as we wish to use uidNumber and gidNumber attributes we've added > to > > users and groups in AD > > 3. at this point I attempted to query AD records but couldn't, so I > updated > > /etc/krb5.conf to set the default realm and to add the "dns_lookup_kdc > > true" option, which allowed me to kinit successfully but still not see > > records > > 4. I added the following two idmap configuration options to > > /etc/samba/smb.conf and was then able to retrieve user and group records > > from AD, but the group members aren't included: > > > > idmap config BSOE : unix_nss_info = yes > > idmap config BSOE : unix_primary_group = yes > > > > # getent passwd BSOE\\eshell > > BSOE\eshell:*:3392:325::/soe/eshell:/bin/bash > > # getent group "BSOE\\staff-group" > > BSOE\staff-group:x:552: > > > > 5. I've found that querying some groups returns no information, perhaps > > because of low gidNumber values (BSOE\staff-group has gidNumber 552): > > > > # getent group "BSOE\\staff-group" > > # > > > > 6. I tried changing the idmap config range from 500-999999 to 100-999999 > > but it doesn't seem to affect these queries. > > > > > -------------------------------------------------------------------------------- > > > > Some things appear to be working properly. I can "su - BSOE\\eshell" > and I > > am able to mount and access the NFS directories appropriately. "id > eshell" > > and "id BSOE\\eshell" return the same information. I can also > successfully > > authenticate to samba with my AD account, but then I am told that there > are > > no available shares. I'm guessing that this is related to the NSS group > > issues I'm having. > > > > Why can't I see the members of some groups? How do I debug this > behavior? > > > > Why isn't samba able to mount the NFS shares after a user has > authenticated > > when I can do so in a shell by becoming that user on the samba host? > > > > Thanks in advance for any help you can provide. > > Lets start with the easiest part, can you post your smb.conf > > Rowland > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >-- Eric Shell BSOE Technical Staff eshell at ucsc.edu 831 459 4919 Baskin Engineering, Room 313
On 09/07/2019 19:02, Eric Shell via samba wrote:> Ugh, I knew I forgot something. Here is smb.conf: > > --- > > [global] > kerberos method = system keytab > template homedir = /soe/%U > workgroup = BSOE > template shell = /bin/bash > security = ads > realm = AD.SOE.UCSC.EDU > idmap config BSOE : schema_mode = rfc2307 > idmap config BSOE : range = 100-999999 > idmap config BSOE : backend = ad > idmap config BSOE : unix_nss_info = yes > idmap config BSOE : unix_primary_group = yes > idmap config * : range = 10000000-10999999 > idmap config * : backend = tdb > winbind use default domain = no > winbind refresh tickets = yes > winbind offline logon = yes > winbind enum groups = no > winbind enum users = no > > ################################################################################ > # You should not define any shares in this file directly, use > shares.conf. # > ################################################################################ > > include = /etc/samba/shares.conf > > --- > > Here's an example of one of the share configurations from shares.conf, > which are uniform: > > --- > > [backups] > path = /notbackedup/backups > comment = Window Servers Backups > create mask = 0640 > directory mask = 0750 > force create mode = 0640 > force directory mode = 0750 > force group = backups > valid users = +BSOE\backups-group +backupsNot much wrong there, except I would use 'kerberos method = secrets and keytab' instead of 'kerberos method = system keytab' For the winbind 'ad' backend to work, you need to set up smb.conf correctly (you seem to have) and give any AD users you want to be visible on Unix, a unique number stored in the uidNumber attribute in the users AD object, you also need to give the Domain Users group a gidNumber attribute containing a number. if you use 'unix_primary_group = yes', then you can give your users a gidNumber attribute containing the gidNumber of the required group. All of these numbers must be inside the range set in smb.conf (in your case '100-999999'). Using such a low start number does come with its own problems, the low numbers could cause problems with the Unix system users & groups. You seem to be hitting the problem a lot of people have hit, Samba historically used low ID's because it was thought to be okay, time seems to have proven otherwise. Rowland
Hi Rowland, Thanks for the prompt reply. The gidNumber attribute is set to the appropriate primary UNIX group for each user already. Are there any ways to work around the ID issue, or at least to mitigate some of the consequences? We looked at updating uid/gid values across the board but there is so much data owned by existing users and groups that we haven't been able to proceed. On Tue, Jul 9, 2019 at 11:32 AM Rowland penny via samba < samba at lists.samba.org> wrote:> On 09/07/2019 19:02, Eric Shell via samba wrote: > > Ugh, I knew I forgot something. Here is smb.conf: > > > > --- > > > > [global] > > kerberos method = system keytab > > template homedir = /soe/%U > > workgroup = BSOE > > template shell = /bin/bash > > security = ads > > realm = AD.SOE.UCSC.EDU > > idmap config BSOE : schema_mode = rfc2307 > > idmap config BSOE : range = 100-999999 > > idmap config BSOE : backend = ad > > idmap config BSOE : unix_nss_info = yes > > idmap config BSOE : unix_primary_group = yes > > idmap config * : range = 10000000-10999999 > > idmap config * : backend = tdb > > winbind use default domain = no > > winbind refresh tickets = yes > > winbind offline logon = yes > > winbind enum groups = no > > winbind enum users = no > > > > > ################################################################################ > > # You should not define any shares in this file directly, use > > shares.conf. # > > > ################################################################################ > > > > include = /etc/samba/shares.conf > > > > --- > > > > Here's an example of one of the share configurations from shares.conf, > > which are uniform: > > > > --- > > > > [backups] > > path = /notbackedup/backups > > comment = Window Servers Backups > > create mask = 0640 > > directory mask = 0750 > > force create mode = 0640 > > force directory mode = 0750 > > force group = backups > > valid users = +BSOE\backups-group +backups > Not much wrong there, except I would use 'kerberos method = secrets and > keytab' instead of 'kerberos method = system keytab' > > For the winbind 'ad' backend to work, you need to set up smb.conf > correctly (you seem to have) and give any AD users you want to be > visible on Unix, a unique number stored in the uidNumber attribute in > the users AD object, you also need to give the Domain Users group a > gidNumber attribute containing a number. if you use 'unix_primary_group > = yes', then you can give your users a gidNumber attribute containing > the gidNumber of the required group. All of these numbers must be inside > the range set in smb.conf (in your case '100-999999'). Using such a low > start number does come with its own problems, the low numbers could > cause problems with the Unix system users & groups. > > You seem to be hitting the problem a lot of people have hit, Samba > historically used low ID's because it was thought to be okay, time seems > to have proven otherwise. > > Rowland > > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >-- Eric Shell BSOE Technical Staff eshell at ucsc.edu 831 459 4919 Baskin Engineering, Room 313