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 [EMAIL PROTECTED]
John H Terpstra wrote:
Tony,
I look forward to your findings in detail.
Thanks.
- 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)
BUT ALSO,
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.
Tony
-------------------
John H Terpstra wrote:
Tony,
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.
Cheers,
John T.
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
