[Samba] Re: Samba 3.0.3 on FC2: windows machine cannot join domain

Tony Fugere tony_fugere at ncsu.edu
Fri Sep 24 19:29:55 GMT 2004

So I came into work today and did the following:

1. Changed my smb.conf to:
   log level = 0 rpc_srv:5 sam:5
   log file = /var/log/samba/%m.log
   max log size = 0
   add machine script = /path/to/smbldap-tools/smbldap-useradd -w "%u"

2. Deleted the INFERIOROS$ entry in LDAP.
3. Deleted the ROOT$ entry in LDAP.
4. Attempted to join the domain from INFERIOROS.

It was successful. Something, somehow, is different. The logs were not 
very beneficial as the process was successful. I tried to put the 
smb.conf back like I had it using %m and the process was still 
successful. Comparing the use of %u and %m in the logs also appeared to 
be similar enough to not report it.

I tried many combinations of the scenario above including

- with the incomplete root$ machine in LDAP,
- without root$,
- changing the NetBIOS host name of the machine, and
- switching between %u and %m

All the possible combinations of scenarios were all successful in adding 
a machine to the domain.

Something has seemed to work itself out overnight. I think it was the 
Samba Gremlins. Whatever has changed is not producing the same results I 
was getting yesterday. Looking into the possible %-based variables, I 
can speculate that %U would cause this trouble, but %u was the culprit 
previously. I don't want to test it on my functional server now that 
I've got it working perfectly.

However, this raises a few questions:

  1. Why does %m work? I understand why, but shouldn't it be used
     instead of %u?
  2. Does %m work for you (or anyone that has had success with %u)?
  3. Could it have been some sort of Windows Cache or Samba Cache type
     of issue?<>

<>I think that finding the answer to these questions as well as finding 
the exact conditions that caused my problem should be resolved for 
Samba, the smbldap-tools, and possibly OpenLDAP (if it is involved with 
this problem). This may be something that the samba team looks into. I 
am willing to try to reproduce the results, but the domain I have had 
this trouble on is now my main PDC, so it will not be put to these 
rigorous tests anymore (if it ain't broke don't fix it). Thanks again 
John for the helpful insights that led me to work on this issue a bit 
more intelligently.

Tony Fugere
tony_fugere at ncsu.edu

John H Terpstra wrote:

>I look forward to your findings in detail.
>- John T.
>On Thursday 23 September 2004 23:35, Tony Fugere wrote:
>>After further review, I don't believe this is the proper approach to the
>>problem. It seems to me that the %u is being used ambiguously. The logic
>>of how the published API of the variables and the call to the
>>smbldap-useradd program makes it important for the documenters to
>>understand what the tools are doing... not what is happening in samba.
>>We can see what is happening with the tools by looking at lines 84 to 92
>>of smbldap-useradd:
>># Read only first @ARGV
>>my $userName = $ARGV[0];
>># For computers account, add a trailing dollar if missing
>>if (defined($Options{'w'})) {
>> if ($userName =~ /[^\$]$/s) {
>>   $userName .= "\$";
>> }
>>My understanding is that if I am logged into an XP machine named
>>"INFERIOROS" and want to join the Domain "SAMBADOMAIN", When the request
>>is placed by INFERIOROS, the machine running samba for SAMBADOMAIN tries
>>to look up INFERIOROS. It sees that there is no machine in the (LDAP in
>>this case) database. So, it turns to the smb.conf file to see what it
>>should do to add the machine and sees:
>>add machine script = /usr/local/sbin/smbldap-useradd -w "%m"
>>After processing through the lines mentioned above of smbldap-useradd
>>you would end up with $userName == INFERIOROS$
>>In line 218 where the subroutine add_posix_machine from smbldap_tools.pm
>>is called the $userName gets passed into line 373 of that perl module
>>which reads:
>>my $add = $ldap->add ( "uid=$user,$config{computersdn}.....
>>Don't we want the $user passed in to be the machine name in this case
>>since it is a machine we are adding and not a user?
>>This userName gets passed into subsequent functions and I eventually end
>>up with a well-formed machine in LDAP called INFERIOROS$ with the four
>>objectClasses: top, inetOrgPerson, posixAccount, and sambaSAMAccount all
>>filled with their respective attributes. On the other hand, when I have
>>the smb.conf using:
>>add machine script = /usr/local/sbin/smbldap-useradd -w "%u"
>>I end up with an incomplete machine record uid=INFERIOROS$ in LDAP that
>>only holds the objectClasses: top, inetOrgPerson, and posixAccount (I
>>assume this is from the module handling automatic account creation that
>>you mentioned)
>>I end up with an incomplete machine record uid=root$ (my admin user to
>>join the domain) with the same three objectClasses and their attributes.
>>(This is coming from the smbldap-useradd tool)
>>The sambaSAMAccount objectClass is never created for the INFERIOROS$
>>record and I get the error "Cannot join domain, the user name could not
>>be found" (approximately).
>>Obviously, this is not the desired result.
>>Without investigation into the rpc_src and sam modules and having the
>>log level configured to report their errors, it is obvious that
>>something is wrong here. I understand that you, as well as many others,
>>have not had trouble with %u, but the fact remains that the %u is
>>ambiguous. The %m makes much more sense for machine name; especially
>>since it is used elsewhere in the smb.conf. Should the ambiguity of %u
>>be plucked through in the samba code so that %m is used for machines
>>instead of this substitution? I will still investigate it tomorrow to
>>deliver the results of debugging the modules in contest to compare and
>>contrast the differences in our systems.
>>The default shell for the tools in the smbldap.conf is /bin/bash,
>>luckily we've changed ours to /bin/false because none of our users
>>(except a few) need shell access. Is it also a possible security problem
>>to have this root$ machine that has no password? I will investigate that
>>as well to see the implications of a machine with no password and
>>/bin/bash shell access.
>>Tony Fugere
>>Tony Fugere wrote:
>>I'm pretty sure that we have our problems solved by using %m, but I will
>>triple check and post results in a few hours. I don't really want to
>>mislead anyone into having a six month struggle as I have had with this.
>>John H Terpstra wrote:
>>I do not have any proof to contradict your information, however, the source
>>code suggests that this advice is perhaps suspect.
>>The particular module that handles automatic account creation is in
>>~samba/source/rpc_server/srv_samr_nt.c and specifically at line 2253.
>>Here is the very line that does the parameter substitution:
>> all_string_sub(add_script, "%u", account, sizeof(add_script));
>>As you can see, it is the "%u" parameter that is being substituted. Maybe I
>>am reading this incorrectly? However, I have performed many hundreds of
>>installations and have always used the "%u" parameter - and it has worked.
>>Given this background I respectfully suggest that we should understand
>>precisely what is happening in your situation by examining the samba logs
>>for the use of this function give both the "%u" and again with the "%m"
>>parameters. You can turn up the debug level on just this module by setting
>>in smb.conf [globals]:
>>	log level = 0 rpc_srv:5 sam:5
>>	log file = /var/log/samba/%m.log
>>	max log size = 0
>>Please would test this and report the findings. If our documentation is in
>>error I want to fix it immediately.
>>Thanks so much for your input.
>>John T.

More information about the samba mailing list