(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 ---- [global] 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 = 130.95.13.3 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 S-1-5-352321536-3342141748-1574249315-1264630062 to S-1-5-21-3342141748-1574249315-1264630062 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`.