[Samba] help, please, troubleshooting winbind testing during setup of Samba 4 AD member server
d3r3kshaw at gmail.com
Sat Jan 17 03:19:15 MST 2015
On 15-01-13 01:50 AM, Rowland Penny wrote:
> On 13/01/15 01:07, BISI wrote:
>> Found it! (Thanks to Louis van Belle and Rowland Penny for their
>> The wiki page for
>> *really* needs a note about this to be added. It will save a lot of
>> frustration and wasted time for others coming behind.
>> The reason I say this is that a default Windows Server 2008 R2
>> install, *does not provide* the necessary tools to allow a Samba 4 AD
>> Member Server to enumerate the users and groups for the domain. So it
>> will join the domain, and wbinfo -u and wbinfo -g report info, but the
>> member server is still essentially useless - unavailable to the domain
>> Thus, if you using the wiki as a guide, with a Windows server 2008 R2
>> Domain Controller, you will hit the same wall as I have.
>> To fix this situation, somewhere in "Section 2 Preconditions" there
>> should be a mention (say, section 2.3) of installing said tools.
>> Feel free to cut and paste the following in place if you have editing
>> privileges (formatted for mediaWiki).
>> ==Windows Domain Controller==
>> '''This will require a server reboot'''
>> If you have a windows Domain Controller you are '''strongly advised'''
>> add the "Identity Management for Unix" Role (IDMU), so that you will
>> be able to use the schema_mode = rfc2307 option of Samba to keep
>> userIDs in sync on multiple member servers. Not doing so invites a
>> lot of problems, and all the documentation presented here assumes you
>> will be using the schema_mode = rfc2307 option.
>> Here's what Microsoft have to say about IDMU:
>> <blockquote>Identity Management for UNIX is deprecated. If you try to
>> upgrade a computer that runs Identity Management for UNIX, you may
>> receive a warning that it must be removed before the upgrade can
>> proceed. In that case, see Installing or removing Identity Management
>> for UNIX by using a command line.</blockquote>
>> [http://technet.microsoft.com/en-us/library/cc772571.aspx MS Technet
>> Article cc772571]
>> *Damn the torpedos! (install IDMU on server 2008 r2)
>> #Control Panel -> administrative tools -> server manager
>> #Expand Roles
>> #Click on "Active Directory Domain Services" (AD DS, in the technet docs)
>> #Scroll down to "Role Services" section
>> #Click on "Add Role Services" (link)
>> #Select "Identity Management for UNIX"
>> ##That will also select 3 sub-services, including "Server for Network
>> Information Services" and "Administration Tools"
>> #Next (button)
>> #Install (button)
>> Now you can use ADUC to see and set the "UNIX Attributes" tab in
>> properties for users and groups.
>> Next step is to set the UID and GID for users/groups you want to be
>> able to see from the Member Server.
>> some people say you need to to match your settings in the smb.conf for
>> the member server (or vice-versa). I'm not sure that's true -- windows
>> defaults to 10000, and using that number or 500 had no apparent affect
>> on the reported UID or GID at the member server.
>> So, using the example smb.conf from the
>> AD Member Server page], matching the UID/GID numbers means:
>> <blockquote> idmap config SAMDOM:range = 500-40000 </blockquote>
>> nb - this is probably *not* a good range to use, since 500 is well
>> within the normal linux userID ranges.
>> Start with the groups in Builtin OU ('cause the users need a primary
>> group) (Assuming a stock Server 2008 R2 Server Standard install)
>> NIS domain: samdom; GID: 500
>> Now go to the Users OU and do the groups:
>> Domain Admins
>> NIS Domain: samdom; GID: 501
>> Domain Users
>> NIS Domain: samdom; GID: 502
>> Enterprise Admins
>> NIS Domain: samdom; GID 503
>> NOTE - I think you have to manually keep track of the NEXT UID number
>> 'cause ADUC always pops up with 10000 by default (I'm sure there's a
>> way to configure it -- I've spent enough time on this already. Future
>> me (or future you) can figure that out.
>> Now edit the built-in Administrator user
>> NIS Domain: samdom; UID: 500; Login Shell: /bin/whatever; Home
>> Directory: /home/administrator; Primary group name/GID:Administrators
>> (Should be what you set up in the Builtin OU)
>> Now edit any existing users in any other OUs you might be using...
>> NIS Domain: samdom; UID: 501; Login Shell: /bin/false; Home
>> Directory: /home/fred Primary group name/GID: Domain Users
>> Now you should be able to enumerate the users and groups of the AD
>> Domain from the member server with the tests shown in Section 9 of the
>> wiki (id DomainUser, getent passwd, etc.). At least I was finally
>> able to do so.
>> On 15-01-08 07:16 PM, BISI wrote:
>>> Hello, all!
>>> Well, third time is *not* the charm for me. (I've been through the
>>> process 3 times with 3 different DCs).
>>> I am trying to set up a member server, using Samba 4.1.14, and washing
>>> out when getting to the winbind testing. I've tried ignoring the failure
>>> and pressing on, but that didn't get anywhere.
>>> In this instance, I have a freshly-installed, configured and functioning
>>> Server 2008r2 Domain Controller, operating at server 2003 forest and
>>> domain functional level.
>>> following the instructions in:
>>> Completely stock compile from the tarball. I am using Debian 7.7
>>> (wheezy), and samba 4.1.14,
>>> ./configure --with-ads --with-shared-modules=idmap_ad --enable-cups \
>>> make quicktest passes:
>>> make quicktest
>>> ...ALL OK (2086 tests in 310 testsuites)
>>> ...A summary with detailed information can be found in:
>>> ... ./st/summary
>>> ...'testonly' finished successfully (11m24.779s)
>>> ./st/summary is found here:
>>> daemons started manually with
>>> /usr/local/samba/sbin/smbd --daemon -l /var/log/samba/ -d 1
>>> /usr/local/samba/sbin/nmbd --daemon -l /var/log/samba/ -d 1
>>> /usr/local/samba/sbin/winbindd --daemon -l /var/log/samba/ -d 1
>>> The commands:
>>> wbinfo -u
>>> wbinfo -g
>>> show the users and groups from the AD Domain.
>>> but the other tests
>>> # id DomainUser
>>> # getent passwd
>>> # getent group
>>> # chown DomainUser:DomainGroup file
>>> # chgrp DomainGroup file
>>> do not get any information from the domain, seemingly only working with
>>> the local user information.
>>> Where do I begin troubleshooting?
>>> Any help/guidance is greatly appreciated.
>>> my smb.conf is here:
>>> log.winbindd (created with debug level 1) is here:
>>> Kerberos seems to be working:
>>> root at testmember:~# klist
>>> Ticket cache: FILE:/tmp/krb5cc_0
>>> Default principal: userID at HO.NAME.ORG
>>> Valid starting Expires Service principal
>>> 08/01/2015 18:46 09/01/2015 04:46 krbtgt/HO.NAME.ORG at HO.NAME.ORG
>>> renew until 09/01/2015 18:46
>>> root at testmember:~# cat /etc/nsswitch.conf
>>> # /etc/nsswitch.conf
>>> passwd: compat winbind
>>> group: compat winbind
>>> shadow: compat
>>> DNS seems to be working:
>>> root at testmember:~# host -t SRV _ldap._tcp.ho.name.org.
>>> _ldap._tcp.ho.name.org has SRV record 0 100 389 namedc.ho.name.org.
>>> root at testmember:~# host -t SRV _kerberos._udp.ho.name.org.
>>> _kerberos._udp.ho.name.org has SRV record 0 100 88 namedc.ho.name.org.
>>> root at testmember:~# host -t A namedc.ho.name.org.
>>> namedc.ho.name.org has address 192.168.8.1
>>> Thanks in advance for any help!
> Why use the windows group RID's ?
Because I was ignorant of what I was doing -- I was taking the lead from
the range set in the idmap example given in the "AD Member Server HowTo"
(set up a basic smb.conf). Like I said in the post - "Future
me ... can figure that out"
> Just start at 10000 and go from there,
> Oh and windows stores the uid & gid numbers in the msSFU30MaxUidNumber &
> msSFU30MaxGidNumber attributes. If you had started from 10000, windows
> would have created these for you
Yep - discovered that after I got the test member server working.
More information about the samba