[Samba] Member server - winbind unable to resolve users/groups

Rowland Penny rowlandpenny at googlemail.com
Fri Apr 3 14:54:16 MDT 2015


On 03/04/15 21:29, Andrey Repin wrote:
> Greetings, Rowland Penny!
>
>>>>>>>> I'm trying to get the former PDC back into domain after performing a
>>>>>>> classic
>>>>>>>> migration.
>>>>>>>> AD DC is running fine... if you can call it that.
>>>>>>>> I've edited the smb.conf and nsswitch.conf as suggested in Wiki article,
>>>>>>> and
>>>>>>>> rejoined the domain. Went fine apart from failed DNS update with local
>>>>>>> zone.
>>>>>>>
>>>>>>>> # net ads testjoin
>>>>>>>> Join is OK
>>>>>>>> But there's no data in getent, and domain users are unable to
>>>>>>> authenticate on
>>>>>>>> the server.
>>>>>>>> So, where do I start looking?
>>>>>> Please check your  /etc/nsswitch.conf file, it should look contains this,
>>>>>> passwd: compat winbind
>>>>>> group:    compat winbind
>>>>>> For more information, please go through Samba Wiki first,
>>>>>> https://wiki.samba.org/index.php/Setup_a_Samba_AD_Member_Server
>>>>> Please read the message - I explicitly stated that nsswitch.conf is amended as
>>>>> suggested on the wiki.
>>>>>
>>>>>
>>>> OK, so you upgraded an NT-4 style PDC to AD with 'samba-tool domain
>>>> classicupgrade', this should have given you users with uidNumber
>>>> attributes and groups with gidNumber attributes.
>>>> If,as you said, you used the smb.conf from the member server wiki page,
>>>> you will have something like this in your smb.conf:
>>>>       idmap config *:backend = tdb
>>>>       idmap config *:range = 2000-9999
>>>>       idmap config SAMDOM:backend = ad
>>>>       idmap config SAMDOM:schema_mode = rfc2307
>>>>       idmap config SAMDOM:range = 10000-99999
>>>> Two questions:
>>>> Did you change 'SAMDOM' to your workgroup name ?
>>>> Are your users & groups uidNumber & gidNumber attributes inside the
>>>> '10000=99999' range ?
>>> It was a little more complicated process, than that.
>>>
>>> Host: Ubuntu 12.04 running Samba 3.6.3->4.1.11 and LXC 1.0.7 stable.
>>>
>>> On host, I've set up container DC1, copied over the 3.6.3 TDB's from host and
>>> performed classicupgrade with hostname change. After initial failure and a
>>> month of head cracking, it somehow worked out on April 1st.
>>>
>>> The container runs as it could, resolving uids to domain names within itself,
>>> at least.
>>>
>>> Now, I need to get the same resolution on the host.
>>> The Samba 3 configuration files were moved away on the host before Samba
>>> upgrade, so that I could have one more backup copy of the configuration, if
>>> things go wrong.
>>>
>>> After upgrading Samba, I've edited {smb,nsswitch}.conf as outlined on the
>>> Wiki, and then commanded to join the AD.
>>> Join went fine except for a notice "unable to update DNS record for
>>> userl.ccenter.lan".
>>> After that, I removed startup blocks on smbd/nmbd/winbind and rebooted
>>> everything.
>>>
>>> Currently, the situation is as follows:
>>>
>>> DC1 (AD DC): http://pastebin.com/WncfgLb6
>>>
>>> root at dc1:~# smbclient -L dc1 -U domainuser
>>> Enter domainuser's password:
>>> Domain=[CCENTER] OS=[Unix] Server=[Samba 4.1.11-Ubuntu]
>>>
>>>           Sharename       Type      Comment
>>>           ---------       ----      -------
>>>           netlogon        Disk
>>>           sysvol          Disk
>>>           IPC$            IPC       IPC Service (Samba 4.1.11-Ubuntu)
>>> Domain=[CCENTER] OS=[Unix] Server=[Samba 4.1.11-Ubuntu]
>>>
>>>           Server               Comment
>>>           ---------            -------
>>>
>>>           Workgroup            Master
>>>           ---------            -------
>>>
>>> root at dc1:~# smbclient -L userl -U domainuser
>>> Enter domainuser's password:
>>> session setup failed: NT_STATUS_LOGON_FAILURE
>>>
>>> USERL (member server): http://pastebin.com/25Lx6z9v
>>>
>>> root at userl:~# net ads testjoin
>>> Join is OK
>>>
>>> root at userl:~# smbclient -L dc1 -U domainuser
>>> Enter domainuser's password:
>>> Domain=[CCENTER] OS=[Unix] Server=[Samba 4.1.11-Ubuntu]
>>>
>>>           Sharename       Type      Comment
>>>           ---------       ----      -------
>>>           netlogon        Disk
>>>           sysvol          Disk
>>>           IPC$            IPC       IPC Service (Samba 4.1.11-Ubuntu)
>>> Domain=[CCENTER] OS=[Unix] Server=[Samba 4.1.11-Ubuntu]
>>>
>>>           Server               Comment
>>>           ---------            -------
>>>
>>>           Workgroup            Master
>>>           ---------            -------
>>>
>>> root at userl:~# smbclient -L userl -U domainuser
>>> Enter domainuser's password:
>>> session setup failed: NT_STATUS_LOGON_FAILURE
>>>
>>> Looking at winbind/idmap logs,
>>>
>>> [2015/04/03 21:16:17.636654, 10, pid=8618, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4446(pack_tdc_domains)
>>>     pack_tdc_domains: Packing domain CCENTER (ADS.CCENTER.LAN)
>>> [2015/04/03 21:16:17.636687, 10, pid=8618, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:230(add_trusted_domain)
>>>     idmap config CCENTER : range = 1000-50000
>>> [2015/04/03 21:16:17.636720,  2, pid=8618, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:255(add_trusted_domain)
>>>     Added domain CCENTER ADS.CCENTER.LAN S-1-5-21-1031481445-3291699540-3997755762
>>> [2015/04/03 21:16:17.636766, 10, pid=8618, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cm.c:561(set_domain_online_request)
>>>     set_domain_online_request: called for domain CCENTER
>>> [2015/04/03 21:16:17.636803, 10, pid=8618, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cm.c:596(set_domain_online_request)
>>>     set_domain_online_request: domain CCENTER was globally offline.
>>>
>>> Eh? What the? Why? Google says it may be an issue with DNS, but mine works
>>> fine. Especially since a few lines before it successfully contact AD DC.
>>>
>>>
>> I am struggling to understand this setup, you have created a samba AD DC
>> running on Ubuntu 12.04 inside a container (docker  ??),
> docker is a management tool for LXC, which is an isolation solution and have
> its own management tools. docker is fine when you need to deploy many similar
> instances of an application, but for a single container, it is just not
> needed.
> For simplicity, you can presume that it is a separate system running elsewhere
> on the network. Answering your later question, yes, I have full network
> connectivity, I can ping and ssh between both, and browse shares of a DC from
> the member server using either credentials. (See above.)
>
>> you then seem to have altered the AD DCs smb.conf for some reason, can I ask
>> why ?
> Multiple reasons at first, but at this point, it is a template I could just
> copy to a member server and have it run with only a single line edit. The
> settings are either sensible, but not necessary, or completely irrelevant for
> a DC, as far as I can tell.
>
>> You then setup a member server, joined it to the domain, but now cannot
>> connect to the member server from the DC via smbclient, is this correct ?
> I can't connect to a member server using domain user credentials.
> This would be more correct statement.
>
>> what have you got in:
>> /etc/resolv.conf
>> /etc/krb5.conf
> Both give exactly same results:
>
> # cat /etc/krb5.conf
> cat: /etc/krb5.conf: No such file or directory
> (Erm, should I have it? What package I'm missing, if yes?)

Yes you should, it should contain this:

[libdefaults]
      default_realm = ADS.CCENTER.LAN
      dns_lookup_realm = false
      dns_lookup_kdc = true

Have you got all of these packages installed:

krb5-config libnss-winbind libpam-winbind libpam-krb5 krb5-user

>
> # cat /etc/resolv.conf
> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
> #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
> nameserver 127.0.0.1
> search ccenter.lan
>
>> This on both machines
> In case of a member server, 127.0.0.1 point to a local bind9, which is set to
> forward ads.ccenter.lan to the DC. The resolution DO works correctly.

Just point /etc/resolv.conf at the DC, also ccenter.lan is not 
ads.ccenter.lan

Rowland

> 127.0.0.1#35321: query: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ADS.CCENTER.LAN IN SRV + (127.0.0.1)
> ;; ANSWER SECTION:
> _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ADS.CCENTER.LAN. 503 IN SRV 0 100 389 dc1.ads.ccenter.lan.
>
> 127.0.0.1#55300: query: dc1.ads.ccenter.lan IN AAAA + (127.0.0.1)
> 127.0.0.1#36282: query: dc1.ads.ccenter.lan.ccenter.lan IN AAAA + (127.0.0.1)
> (no answer - IPv6 resolution disabled)
>
> 127.0.0.1#47102: query: dc1.ads.ccenter.lan IN A + (127.0.0.1)
> ;; ANSWER SECTION:
> dc1.ads.ccenter.lan.    373     IN      A       192.168.17.4
>
> 127.0.0.1#58461: query: _kerberos._udp.ADS.CCENTER.LAN IN SRV + (127.0.0.1)
> ;; ANSWER SECTION:
> _kerberos._udp.ADS.CCENTER.LAN. 324 IN  SRV     0 100 88 dc1.ads.ccenter.lan.
>
>> can you ping from each machine to the other, both by ip and hostname ?
>> what does 'host -t SRV _ldap._tcp.ads.ccenter.lan.' show ?
> root at dc1:~# host -t SRV _ldap._tcp.ads.ccenter.lan.
> _ldap._tcp.ads.ccenter.lan has SRV record 0 100 389 dc1.ads.ccenter.lan.
>
> root at userl:~# host -t SRV _ldap._tcp.ads.ccenter.lan.
> _ldap._tcp.ads.ccenter.lan has SRV record 0 100 389 dc1.ads.ccenter.lan.
>
>> does the 'container' have all the required ports open ?
> If logs are to be trusted, it even able to list users and groups.
>
> log.wb-CCENTER
> [2015/04/03 22:55:59.314002,  3, effective(0, 0), real(0, 0)] ../source3/libsmb/namequery.c:3102(get_dc_list)
>    get_dc_list: preferred server list: "dc1.ads.ccenter.lan, *"
> [2015/04/03 22:55:59.318397,  3, effective(0, 0), real(0, 0)] ../source3/libads/ldap.c:680(ads_connect)
>    Successfully contacted LDAP server 192.168.17.4
> [2015/04/03 22:55:59.320717,  3, effective(0, 0), real(0, 0)] ../source3/libads/ldap.c:723(ads_connect)
>    Connected to LDAP server dc1.ads.ccenter.lan
> [2015/04/03 22:55:59.325436,  3, effective(0, 0), real(0, 0)] ../source3/libads/sasl.c:955(ads_sasl_spnego_bind)
>    ads_sasl_spnego_bind: got OID=1.2.840.48018.1.2.2
> [2015/04/03 22:55:59.325466,  3, effective(0, 0), real(0, 0)] ../source3/libads/sasl.c:955(ads_sasl_spnego_bind)
>    ads_sasl_spnego_bind: got OID=1.2.840.113554.1.2.2
> [2015/04/03 22:55:59.325498,  3, effective(0, 0), real(0, 0)] ../source3/libads/sasl.c:955(ads_sasl_spnego_bind)
>    ads_sasl_spnego_bind: got OID=1.3.6.1.4.1.311.2.2.10
> [2015/04/03 22:55:59.325527,  3, effective(0, 0), real(0, 0)] ../source3/libads/sasl.c:964(ads_sasl_spnego_bind)
>    ads_sasl_spnego_bind: got server principal name = not_defined_in_RFC4178 at please_ignore
> [2015/04/03 22:55:59.325655,  3, effective(0, 0), real(0, 0)] ../lib/krb5_wrap/krb5_samba.c:499(ads_krb5_mk_req)
>    ads_krb5_mk_req: krb5_cc_get_principal failed (No such file or directory)
> [2015/04/03 22:55:59.333493,  3, effective(0, 0), real(0, 0)] ../lib/krb5_wrap/krb5_samba.c:266(ads_cleanup_expired_creds)
>    ads_cleanup_expired_creds: Ticket in ccache[MEMORY:winbind_ccache] expiration Sat, 04 Apr 2015 08:55:59 MSK
> [2015/04/03 22:55:59.373034,  3, effective(0, 0), real(0, 0)] ../source3/winbindd/winbindd_ads.c:378(query_user_list)
>    ads query_user_list gave 19 entries
>
> This is about right.
> root at dc1:~# wbinfo -u | wc -l
> 19
>
> [2015/04/03 22:55:59.374070,  3, effective(0, 0), real(0, 0)] ../source3/lib/util_sock.c:585(open_socket_out_send)
>    Connecting to 192.168.17.4 at port 135
> [2015/04/03 22:55:59.375923,  3, effective(0, 0), real(0, 0)] ../source3/lib/util_sock.c:585(open_socket_out_send)
>    Connecting to 192.168.17.4 at port 1024
> [2015/04/03 22:55:59.516885,  3, effective(0, 0), real(0, 0)] ../source3/winbindd/winbindd_msrpc.c:300(msrpc_sid_to_name)
>    msrpc_sid_to_name: S-1-5-21-1031481445-3291699540-3997755762-513 for domain CCENTER
> [2015/04/03 22:56:13.713563,  3, effective(0, 0), real(0, 0)] ../source3/winbindd/winbindd_ads.c:403(enum_dom_groups)
>    ads: enum_dom_groups
> [2015/04/03 22:56:13.763644,  3, effective(0, 0), real(0, 0)] ../source3/winbindd/winbindd_ads.c:501(enum_dom_groups)
>    ads enum_dom_groups gave 216 entries
>
> This is a bit off, but still close.
> root at dc1:~# wbinfo -g | wc -l
> 211
>
> [2015/04/03 22:56:13.765824,  3, effective(0, 0), real(0, 0)] ../source3/winbindd/winbindd_msrpc.c:300(msrpc_sid_to_name)
>    msrpc_sid_to_name: S-1-5-21-1031481445-3291699540-3997755762-571 for domain CCENTER
> [2015/04/03 22:59:42.388144,  3, effective(0, 0), real(0, 0)] ../source3/winbindd/winbindd_misc.c:161(winbindd_dual_list_trusted_domains)
>    [13765]: list trusted domains
> [2015/04/03 22:59:42.388330,  3, effective(0, 0), real(0, 0)] ../source3/winbindd/winbindd_ads.c:1419(trusted_domains)
>    ads: trusted_domains
> [2015/04/03 23:00:59.189216,  3, effective(0, 0), real(0, 0)] ../source3/winbindd/winbindd_msrpc.c:252(msrpc_name_to_sid)
>    msrpc_name_to_sid: name=CCENTER\DOMAINUSER
> [2015/04/03 23:00:59.189271,  3, effective(0, 0), real(0, 0)] ../source3/winbindd/winbindd_msrpc.c:266(msrpc_name_to_sid)
>    name_to_sid [rpc] CCENTER\DOMAINUSER for domain CCENTER
> [2015/04/03 23:00:59.195301,  3, effective(0, 0), real(0, 0)] ../source3/winbindd/winbindd_ads.c:597(query_user)
>    ads: query_user
>
> But in the end, it just doesn't work. getent doesn't list anything sensible,
> not from explicit request, nor from enumeration.
>
>



More information about the samba mailing list