Web lists-archives.com

Re: [Samba] getent not showing domain users and groups with winbind but works with sssd






On 03.10.2018 17:37, Rowland Penny via samba wrote:
On Wed, 3 Oct 2018 16:57:07 +0200
Peter Milesson via samba <samba@xxxxxxxxxxxxxxx> wrote:


On 03.10.2018 15:38, Rowland Penny via samba wrote:
On Wed, 3 Oct 2018 15:16:50 +0200
Peter Milesson via samba <samba@xxxxxxxxxxxxxxx> wrote:

On 10/3/18 1:09 PM, Rowland Penny via samba wrote:
On Wed, 3 Oct 2018 12:45:11 +0200
Peter Milesson via samba <samba@xxxxxxxxxxxxxxx> wrote:

Hi folks,

I have finally nailed down the problem with the non-functional
getent command when using winbind on a samba member server (AD
domain).

The problem was the entry

       idmap config * : range 3000-9999
No, it wasn't

I used the instructions in
https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
as a template when setting up the server.

Changing the line idmap config to

       idmap config * : range = 16777216-33554431
I have no idea why doing that worked for you, all you have done is
moved the range.

A change of the wiki page would be in order ;-)
Sorry, but that isn't going to happen ;-)

The smb.conf below works well against my Samba AD DC.
and this is mine that works on my Centos 7 VM:

[global]
       workgroup = SAMDOM
       security = ADS
       realm = SAMDOM.EXAMPLE.COM

       dedicated keytab file = /etc/krb5.keytab
       kerberos method = secrets and keytab
       server string = Samba 4 Client %h

       winbind use default domain = yes
       winbind expand groups = 4
       winbind refresh tickets = Yes
       winbind offline logon = yes

       ## map ids outside of domain to tdb files.
       idmap config *:backend = tdb
       idmap config *:range = 3000-9999
       ## map ids from the domain  the ranges may not overlap !
       idmap config SAMDOM : backend = ad
       idmap config SAMDOM : schema_mode = rfc2307
       idmap config SAMDOM : unix_nss_info = yes
       idmap config SAMDOM : range = 10000-999999
       template shell = /bin/bash
       template homedir = /home/%U

       domain master = no
       local master = no
       preferred master = no
       os level = 20
       map to guest = bad user
       host msdfs = no

       # user Administrator workaround, without it you are unable
to set privileges username map = /etc/samba/user.map

       # For ACL support on domain member
       vfs objects = acl_xattr full_audit
       map acl inherit = Yes
       store dos attributes = Yes

       # Share Setting Globally
       unix extensions = no
       reset on zero vc = yes
       veto files
= /.bash_logout/.bash_profile/.bash_history/.bashrc/ hide
unreadable = yes

       # disable printing completely
       load printers = no
       printing = bsd
       printcap name = /dev/null
       disable spoolss = yes

       # logging
       #log level = 10
       log level = 0
       map untrusted to domain = yes

and this is the result:

[root@cen1804 ~]# getent passwd rowland
rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash
[root@cen1804 ~]# getent group Domain\ Users
domain users:x:10000:rowland,...... long list of users.

All I can think of is, you still have sssd installed, I don't.
Or something else isn't set up correctly.

What do the following commands return:

hostname
hostname -s
hostname -d
hostname -f
hostname -i

What is in /etc/resolv.conf
What is in /etc/hosts
What is in /etc/krb5.conf

Rowland

Hi Rowland,

Seems that I forgot to put the IP address of the host in hosts.
SSSD is not installed. I wiped the previous installation, and
installed again. I was very careful not to install SSSD. The
packages I installed were:

samba samba-common samba-client samba-winbind samba-winbind-clients
krb5-workstation authconfig

When trying to use a Windows computer for administration (Computer
management) and connecting to the member server, there is a Windows
message that it was not possible to connect (problems with DCOM).
However, it's possible to browse the share on the samba member, and
create files.

Still works, after several restarts ;-)

Best regards,

Peter

hostname:    smbtest.samdom.local

hostname -s: smbtest

hostname -d:     samdom.local

hostname -f:    smbtest

hostname -i:    192.168.6.79
Oh great, the 'hostname' and 'hostname -f' test results are the
wrong way round. Try opening /etc/hostname in an editor and remove
the domain name i.e. I think you will find it is
'smbtest.samdom.local' make it just 'smbtest'

hosts
====

127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4
::1         localhost localhost.localdomain localhost6
localhost6.localdomain6
192.168.6.79 smbtest.samdom.local smbtest

Try making /etc/hosts look like this:

127.0.0.1 localhost
::1       localhost
192.168.6.79 smbtest.samdom.local smbtest

Now run the 'hostname' tests again

Rowland

Hi Rowland,

I changed the hosts file, and now the hostname and hostname -f
returns the same string (smbtest.samdom.local).
They shouldn't, did you also check if /etc/hostname contains just the
short hostname 'smbtest' ?
If you did, then reboot.

It seems to be on a good way now. What still does not work is the
security tab for the share itself. When I get to the security tab as
Administrator, it behaves like I haven't got permission. When trying
to set/change ownership of the share, Windows shows an error message.
That must wait until Friday, as I'm off tomorrow.

In my smb.conf there is this line:

username map = /etc/samba/user.map

Which contains this line:

!root = SAMDOM\Administrator SAMDOM\administrator Administrator
administrator

With that, Administrator gets mapped to the Unix 'root' user and 'root'
can do anything on Unix.

Rowland

Hi Rowland,

Oops! I didn't take a careful look before, that the hostname file only should contain the name part, not the domain. Now I get:

hostname: smbtest
hostname -s: smbtest
hostname -d: samdom.local
hostname -f: smbtest.samdom.local
hostname -i: 192.168.6.79

The user.map file is there from the beginning, with exactly the same contents as yours. When I run getent passwd administrator I get the response:

administrator:*:10500:10513::/dev/null:/sbin/nologin

After those changes, and a reboot, I also changed the line:

idmap config * : range = 16777216-33554431

to

idmap config * : range = 3000-9999

and noticed that I all the time have used that line without the equals sign! That's probably the explanation, why the getent command failed previously.

What remains now, is to try the security tab on a share.

Thanks a lot for your help! Now it seems there are good prospects for production server migration in the weekend.

Best regards,

Peter


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba