(Posted to Samba list but no response received.)
We have a domain controller running Samba 3.4.7 that is backed onto an OpenLDAP datastore. The domain has no trouble joining Windows XP clients, but we've got a couple of Windows 7 / Windows Server 2008 R2 Standard that we can't join to the domain.
The registry changes suggested in http://wiki.samba.org/index.php?title=Windows7&oldid=4766 have been applied, and a UNIX account for the machine has been created.
While the creation of the object in LDAP appears to succeed, the join fails with super-helpful message "The parameter is incorrect." on the client.
I've attached the output of testparm is below. I will attach NetSetup.LOG and a level 10 debug log from one of the clients. The only thing particularly notable in the NetSetup output is:
NetpSetNetlogonDomainCache: DsEnumerateDomainTrustsW for all trusts failed with ERROR_NOT_SUPPORTED -- retry
workgroup = UCCDOMAIN
server string = %h server
obey pam restrictions = Yes
passdb backend = ldapsam:"ldaps://mussel.ucc.gu.uwa.edu.au ldaps://martello.ucc.gu.uwa.edu.au/"
log level = 2
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
debug pid = Yes
name resolve order = lmhosts host wins bcast
logon path = \\mylah\profiles
logon drive = H:
logon home = \\mylah\%U
domain logons = Yes
os level = 70
preferred master = Yes
domain master = Yes
dns proxy = No
wins server = 220.127.116.11
ldap admin dn = cn=admin,dc=ucc,dc=gu,dc=uwa,dc=edu,dc=au
ldap machine suffix = ou=Computers
ldap passwd sync = only
ldap suffix = dc=ucc,dc=gu,dc=uwa,dc=edu,dc=au
ldap ssl = no
ldap user suffix = ou=People
panic action = /usr/share/samba/panic-action %d
admin users = root, @wheel, @root
Created attachment 5660 [details]
NetSetup.LOG from Windows Server 2008 RC 2
Created attachment 5661 [details]
Level 10 log for client machine (IP address)
Created attachment 5662 [details]
Level 10 log for client machine (machine name)
This still happens with Samba 3.5.2.
I'm wondering if this is being caused by a domain SID that doesn't seem to match the usual conventions: it is S-1-5-352321536-3342141748-1574249315-1264630062 instead of S-1-5-21-something - setting up a test environment with LDAP backing to try and confirm this.
As surmised in comment #5, this was caused by an invalid domain SID. Changing from
by running 'sed' over the LDAP database allowed machines to join the domain.
I suspect the origin of this invalid SID was an endianness bug in Samba on SPARC at one point as our initial setup was done on this platform, and 352321536 in binary is 10101000000000000000000000000 - and 21 in binary is 10101.
However, this has probably been fixed as our newer SPARC machines have sensible SIDs using `net getlocalsid`.