(Apologies in advance for the length of this message - hopefully someone
more familiar with AD will be able to point me in the right direction or
at least help me identify what's going wrong here)..
I'm in the process of putting together a new print server using Samba and
CUPS, and I'm having a bit of trouble getting Samba to properly join the
AD domain. Printing works perfectly, and AD authentication is also
working, after manually configuring /etc/krb5.conf (the significance of
this point wasn't discovered until later).
However, the print queues on the test system refuse to stay listed in AD
for more than 10-20 minutes at a time, which was particularly confusing
until I (somewhat accidentally) noticed that querying the domain users or
groups via wbinfo would cause the queues to be relisted. Further
investigation, including digging through packet dumps, uncovered the
following:
- Joining the domain only works when kinit and 'net ads join' are run
using the domain Administrator account; Samba consistently fails to verify
Kerberos tickets when joined to the domain with any other account that
should ordinarily have permission to join machines - this isn't much of an
issue, as it's easy enough to deal with, but a curious point nonetheless
- The Kerberos libraries resolve and authenticate to the correct domain
controllers when allowed to look up SRV records for the KDC(s), but wbinfo
queries return users/groups from the wrong domain
- Manually setting the domain and KDC in /etc/krb5.conf cause wbinfo to
list users/groups in the correct domain plus those from another domain, as
above
- When /etc/krb5.conf is explicitly configured with a domain and KDC, user
authentication to the shares works as expected, with the exception that
secondary domain groups do not (example: my account is in 'Domain
Admins',
but my primary group is 'Domain Users'; write list =
@"DOMAIN\Domain
Admins" on a share gives me access denied, whereas @"DOMAIN\Domain
Users"
works as expected - changing my primary group in AD alters this behavior)
I took the above into consideration while reading through the packet
traces I have, and I see the following patterns (summarized to only list
the "interesting" behavior, names munged, and analyzed with Ethereal):
When a manually configured krb5.conf is in use, winbind will
- do SRV lookups, followed by A lookups for the correct list of DCs
- connect to one of the DCs, authenticate, and send an RPC_NETLOGON
DsrEnumerateDomainTrusts request
- get a response to that request, that lists (in order) DEADDOMAIN1,
DEADDOMAIN2, WRONGDOMAIN, and DOMAIN (where WRONGDOMAIN is the NT4
domain, DOMAIN is correct, and DEADDOMAINs are trusted domains that no
longer exist - I'm not sure why they're still trusted, but I'm
told
it's necessary)
- send a NetrGetAnyDCName request for WRONGDOMAIN to correct DC
- get a NetrGetAnyDCName response listing NT4DC (the correct domain
controller for WRONGDOMAIN, but not what it should be talking to at all)
- attempt RPC connections to NT4DC, which fail with protocol errors
- second NetrGetAnyDCName cycle, same results
- SAM protocol activity to NT4DC, including a SamrEnumerateGroupsInDomain
call (presumably for wbinfo -g)
- send a NetrGetAnyDCName request for DEADDOMAIN1 to correct DC, get an
error response, fall back to NMB queries which also fail (happens twice)
- repeat above step for DEADDOMAIN2 (also twice)
- perform LDAP queries against correct DC for user or group information in
DOMAIN (Base DN: dc=DOMAIN, dc=COM)
- at this point, wbinfo will spit out the information queried, after an
elapsed time of about 10 seconds - repeated runs happen quickly, I'd
assume the information is cached for some time
When krb5.conf contains no information specific to our domain (realm, kdc,
etc), the above steps are the same, with the exception that LDAP queries
against DOMAIN never take place, and user/group output from wbinfo is
limited to that received from WRONGDOMAIN's DC via the SAM calls. In
either case, DOMAIN is the only one that should be queried at all, and I
don't understand why winbind is asking a proper DC for a domain controller
in WRONGDOMAIN. In both cases, NetrGetAnyDCName requests never happen for
DOMAIN, only the other three (two of which are expected to fail).
The system is running Fedora Core 2, with these packages:
krb5-libs-1.3.3-7
krb5-workstation-1.3.3-7
samba-3.0.3-5
samba-client-3.0.3-5
samba-common-3.0.3-5
Relevant smb.conf information (identical in all cases):
[global]
security = ADS
realm = DOMAIN.COM
workgroup = DOMAIN
netbios name = TESTPRINT2
domain master = no
local master = no
preferred master = no
os level = 0
username map = /etc/samba/smbusers
idmap uid = 10000-20000
idmap gid = 10000-20000
I found a similar problem report here:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&safe=off&threadm=2g6gz-64A-7%40gated-at.bofh.it&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26c2coff%3D1%26scoring%3Dd%26q%3Dsamba%2B%2522wrong%2Bdomain%2522%26btnG%3DSearch
Again, apologies for the length of this message; hopefully it's enough
information to properly describe the issue. I have the packet logs and
log level 10 output from winbind for the above tests available if someone
familiar with the AD interaction wants to see them; any help on this is
greatly appreciated. Thanks!
-Rob
