Red Hat Bugzilla – Bug 429024
After establish trust with AD, wbinfo -u does not work
Last modified: 2008-05-21 13:26:52 EDT
Description of problem:
Setup a samba pdc on rhel5.1 with samba-3.0.25b-0.el5.4, establish a two way
trust with a windows 2003 Avtive Directory domain. Run "wbinfo -u" to get trust
domain users and it failed.
Here is the output
[root@linr5164vs1 ~]# wbinfo -m
[root@linr5164vs1 ~]# wbinfo -u
Error looking up domain users
Created attachment 291892 [details]
Created attachment 291893 [details]
samba config file
Can you raise the debug level to 10 and provide the other winbindd log files too ?
Created attachment 291897 [details]
winbind log on level 10
Created attachment 291898 [details]
wb-LINR51VD1 log on level 10
Created attachment 292014 [details]
Do not use schannel against trusted domains
Created attachment 292015 [details]
Get the right password
The 2 attached patches from post 3.0.28 upstream may solve this specific bug.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Created attachment 292202 [details]
winbindd log after patch
After apply the two patches, it still does not work.
Created attachment 292203 [details]
wb-LINR51VD1 log after patch
Lin, I have reproduced it here, I have a samba version that works, trying to
find out the differences and produce a patch with the minimum changes necessary
Created attachment 293489 [details]
New patch to fix the problem
This patch is working for me against v3-0-test upstream.
It should fix the problem for 3.0.25 too.
Lin can you check if the patch I just attached fixes the problem for you ?
This new patch does not work on my test system. I'm going to set up a clean
system to test the patch and generate logs.
Created attachment 293625 [details]
new log winbindd.log
Created attachment 293626 [details]
new log wb-LINR51VD1.log
Upstream v3-0-test + the above patch works, I have backported a few patches (+
the one I attached here) that makes 3.0.28 works for me in this situation.
I am preparing packages for testing, will let you know when they are done.
if you can tell me what arch you are on I can post on my people page some
packages for testing that should fix this issue.
I'm running a vmware for amd 64bit system.
Created attachment 295318 [details]
log after upgrade to 3.0.28
After upgrade to 3.0.28, It still failed. This time it is a different problem.
It seems trying to find the dc for domain winqanet2.com instead of winqanet2
A quick read at the logs suggest that it is your w2k3r2 server that believes the
DNS domain name is winqanet2.com
Certainly samba has no logic to alter a domain name.
I think this latter error is some DNS/Windows misconfiguration, and is not
related to the original bug which was confirmed.
In our tests so far we reproduced the original issue and successfully solved it
with the packages we are beta testing.
It is a DNS problem. After I configured to use the correct DNS server, it works.
Would it be possible to get copies of the updated packages? Thanks!
I've put some tets packages on my people.redhat.com page, packages will be
available in the 5.2 beta channels when the beta starts.
Turned out this bug was not fixed in all conditions and that dirty caches may
change the behavior when testing. We were still able to reproduce transitory
problems when restarting all services with clean caches.
Created attachment 299950 [details]
Patches to fix some issues still open with trusts
These patches are necessary for trusts to properly work immediately on clean
restarts and empty caches.
Created attachment 300141 [details]
fix idmap with legacy conf, and pam_winbindd on DC vs trusted domains
All the patches so far fixed winbindd auth using wbinfo -a but didn't address a
problem with pam_winbindd which used to try to fetch password policies from the
trusted domain before allowing the user to login.
Pw policies cannot be fetched from trusted domains, this patch fixes that.
Also fixed a regression in idmap code that failed to set up a default idmap
domain using the old compatibility smb.conf syntax
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.