After a net ads join command including a container name (the samba machine name is sbox and the machine account for sbox is pre-created on the DC in the container specified to the net ads join command) winbindd is unable to retrieve the user list of this DC. See the following log (please read on after the log): winbindd version 3.0.2a started. Copyright The Samba Team 2000-2004 lp_load: refreshing parameters Initialising global parameters params.c:pm_process() - Processing configuration file "/var/samba3/smb.conf" adding IPC service adding IPC service added interface ip=192.168.0.1 bcast=192.168.0.255 nmask=255.255.255.0 added interface ip=192.168.0.1 bcast=192.168.0.255 nmask=255.255.255.0 Registered MSG_REQ_POOL_USAGE Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED Connected to LDAP server 192.168.0.201 got ldap server name w2klevel2@GERMANY.EUROPE.TESTCENTER.DE, using bind path: dc=GERMANY,dc=EUROPE,dc=TESTCENTER,dc=DE IPC$ connections done anonymously Connecting to host=W2KLEVEL2 Connecting to 192.168.0.201 at port 445 Doing spnego session setup (blob length=104) got OID=1 2 840 48018 1 2 2 got OID=1 3 6 1 4 1 311 2 2 10 got principal=w2klevel2$@GERMANY.EUROPE.TESTCENTER.DE Doing kerberos session setup lsa_io_sec_qos: length c does not match size 8 add_trusted_domain: GERMANY is an ADS mixed mode domain Added domain GERMANY germany.europe.testcenter.de S-1-5-21-1757981266-113007714-839522115 ads: alternate_name Connected to LDAP server 192.168.0.201 got ldap server name w2klevel2@GERMANY.EUROPE.TESTCENTER.DE, using bind path: dc=GERMANY,dc=EUROPE,dc=TESTCENTER,dc=DE got OID=1 2 840 48018 1 2 2 got OID=1 3 6 1 4 1 311 2 2 10 got principal=w2klevel2$@GERMANY.EUROPE.TESTCENTER.DE krb5_cc_get_principal failed (No credentials cache found) kerberos_kinit_password HOST/sbox@GERMANY.EUROPE.TESTCENTER.DE failed: Client not found in Kerberos database ads_connect for domain GERMANY failed: Client not found in Kerberos database ads: trusted_domains Connected to LDAP server 192.168.0.201 got ldap server name w2klevel2@GERMANY.EUROPE.TESTCENTER.DE, using bind path: dc=GERMANY,dc=EUROPE,dc=TESTCENTER,dc=DE IPC$ connections done anonymously Connecting to host=W2KLEVEL2 Connecting to 192.168.0.201 at port 445 Doing spnego session setup (blob length=104) got OID=1 2 840 48018 1 2 2 got OID=1 3 6 1 4 1 311 2 2 10 got principal=w2klevel2$@GERMANY.EUROPE.TESTCENTER.DE Doing kerberos session setup Connected to LDAP server 192.168.0.200 got ldap server name w2klevel1@EUROPE.TESTCENTER.DE, using bind path: dc=EUROPE,dc=TESTCENTER,dc=DE IPC$ connections done anonymously Connecting to host=W2KLEVEL1 Connecting to 192.168.0.200 at port 445 Doing spnego session setup (blob length=119) got OID=1 2 840 48018 1 2 2 got OID=1 2 840 113554 1 2 2 got OID=1 2 840 113554 1 2 2 3 got OID=1 3 6 1 4 1 311 2 2 10 got principal=w2klevel1$@EUROPE.TESTCENTER.DE Doing kerberos session setup lsa_io_sec_qos: length c does not match size 8 add_trusted_domain: EUROPE is an ADS mixed mode domain Added domain EUROPE europe.testcenter.de S-1-5-21-725345543-1957994488-839522115 ads: trusted_domains Connected to LDAP server 192.168.0.201 got ldap server name w2klevel2@GERMANY.EUROPE.TESTCENTER.DE, using bind path: dc=GERMANY,dc=EUROPE,dc=TESTCENTER,dc=DE IPC$ connections done anonymously Connecting to host=W2KLEVEL2 Connecting to 192.168.0.201 at port 445 Doing spnego session setup (blob length=104) got OID=1 2 840 48018 1 2 2 got OID=1 3 6 1 4 1 311 2 2 10 got principal=w2klevel2$@GERMANY.EUROPE.TESTCENTER.DE Doing kerberos session setup [ 2293]: request interface version [ 2293]: request location of privileged pipe [ 2293]: list users Connected to LDAP server 192.168.0.200 got ldap server name w2klevel1@EUROPE.TESTCENTER.DE, using bind path: dc=EUROPE,dc=TESTCENTER,dc=DE IPC$ connections done anonymously Connecting to host=W2KLEVEL1 Connecting to 192.168.0.200 at port 445 Doing spnego session setup (blob length=119) got OID=1 2 840 48018 1 2 2 got OID=1 2 840 113554 1 2 2 got OID=1 2 840 113554 1 2 2 3 got OID=1 3 6 1 4 1 311 2 2 10 got principal=w2klevel1$@EUROPE.TESTCENTER.DE Doing kerberos session setup rpc: query_user_list ads: fetch sequence_number for GERMANY Connected to LDAP server 192.168.0.201 got ldap server name w2klevel2@GERMANY.EUROPE.TESTCENTER.DE, using bind path: dc=GERMANY,dc=EUROPE,dc=TESTCENTER,dc=DE got OID=1 2 840 48018 1 2 2 got OID=1 3 6 1 4 1 311 2 2 10 got principal=w2klevel2$@GERMANY.EUROPE.TESTCENTER.DE krb5_cc_get_principal failed (No credentials cache found) kerberos_kinit_password HOST/sbox@GERMANY.EUROPE.TESTCENTER.DE failed: Client not found in Kerberos database ads_connect for domain GERMANY failed: Client not found in Kerberos database The problem is that winbindd tries to use the principal HOST/sbox@... which does not exist on the DC. After the following code modification retrieval of user lists from the DC is possible: --- samba-3.0.2a/source/libads/ldap.c.orig 2004-04-24 14:20:34.000000000 +0200 +++ samba-3.0.2a/source/libads/ldap.c 2004-04-24 14:20:49.000000000 +0200 @@ -230,7 +230,7 @@ fstring myname; fstrcpy(myname, global_myname()); strlower_m(myname); - asprintf(&ads->auth.user_name, "HOST/%s", myname); + asprintf(&ads->auth.user_name, "%s", myname); } if (!ads->auth.realm) { It seems that when the samba machine account is created in the default container of the DC and the machine account is created automatically the principal HOST/sbox@... seems to be accessible but when either the machine account is created manually in the DC in the default container or if the machine account on the DC is created in a non-standard container the principal to be accessed is not HOST/sbox@... but sbox@... instead.
Created attachment 480 [details] fix for the HOST/ prefix problem against Samba 3.0.2a The patch is a bit of a hack but it is verified to work. In case of a machine account based connect first HOST/<name>@... is tried and when this fails <name>@... is tried. Thus things work with a samba created machine account as well as with a manually created machine acount in a non-default container.
can't reperoduce this in 3.0.8 so I'm assuming that the bug was addressed during the recent kerberos changes. Please reopen if you can reproduce this against 3.0.8. Thanks.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.