[Samba] Odd Samba 4 ("4.2.0pre1-GIT-b505111"; actually only using client) behaviour #1 - "Could not fetch trust account password for domain ...".

Tris Mabbs TM-Samba201302 at Firstgrade.Co.UK
Mon Aug 12 15:46:03 MDT 2013


                Good day oh technical ones .

 

                I was running Samba 4 (client only, not using it as a DC so
effectively running Samba 3 code from the Samba 4 tree) and, other than a
little "Gotcha!" regarding decoding Kerberos PACs, it was all working
perfectly.

                Then recently I had to upgrade, to "4.2.0pre1-GIT-b505111"
(I had to upgrade the OS on the server running Samba - 'twas "OpenSolaris"
and is now "Solaris 11.1") so I recompiled it all up and installed afresh
(so no ".tdb"s from the previous installation or anything).

 

                It's all working (well, except for the PAC issue which is
still being worked on).  I set the LDAP admin. Password using "smbpasswd
-W".  Kerberos is set up fine.  I'm joined to the domain and both "net ads
testjoin" and "net rpc testjoin" (as well as "wbinfo -t") all agree that the
join is good.  "wbinfo -u" reports my AD users; "wbinfo -g" reports my AD
groups (with the domain prefix removed); "wbinfo -U UUUU" gives me the
correct SID for UID UUUU.

                But here's a funny thing (#1) - "wbinfo -S SSSS" gives me a
UID for SID SSSS.  However it's not the same UID as, when given to "wbinfo
-U UUUU", would return that SID.

 

                Duh?

 

                So the mapping is only currently one way.  UID->SID = OK;
SID->UID = not OK (no error but allocated value not the one stored in the
LDAP schema).

 

                This kinda-almost-sorta works.  The most annoying symptom is
that any UNC path which a workstation accesses winds up with an irritating
"$RECYCLE.BIN" folder being created on it, which every time that UNC path is
accessed results in a "The recycle bin for \\server\path\to\unc\folder
<file:///\\server\path\to\unc\folder>  has become corrupted.  Would you like
to delete it?".

 

                I *suspect* that it may have something to do with the
following messages, which get logged over and over (and over and .) together
in the system log file:

 

Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error] [2013/08/12
20:38:31.381776,  0]
../source3/auth/auth_domain.c:266(domain_client_validate)

Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error]
domain_client_validate: unable to validate password for user  in domain  to
Domain controller PDC.MYDOMAIN. Error was NT_STATUS_NO_SUCH_USER.

Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error] [2013/08/12
20:38:31.382811,  0]
../source3/auth/auth_domain.c:419(check_trustdomain_security)

Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error]
check_trustdomain_security: could not fetch trust account password for
domain MYDOMAIN

 

                And no, that's not me editing out the username and domain in
the second message, it is an empty username and an empty domain name.

 

                It's probably that I've been stupid and missed a
configuration step.  However I can't think what, and I've had a quick dig
around in "auth_domain.c" and can't see what user (and domain) it might be
failing to get from where.

                Plus, of course, it's pure speculation that this is causing
the lack of a coherent bidirectional mapping between UIDs and SIDs .

 

                Anyway, if anyone has any helpful suggestions either to
resolve, or to get to the bottom of, this little hiccup, I'd much appreciate
hearing them :)

 

                Cheers folks!

 

                Tris.



More information about the samba mailing list