Bug 7395 - Windows 7 and Server 2008 R2 cannot join domain: "The parameter is incorrect"
Windows 7 and Server 2008 R2 cannot join domain: "The parameter is incorrect"
Status: RESOLVED INVALID
Product: Samba 3.5
Classification: Unclassified
Component: Domain Control
3.5.2
x64 Windows 2008 R2
: P3 major
: ---
Assigned To: Guenther Deschner
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-27 04:18 UTC by David Adam
Modified: 2010-05-29 12:06 UTC (History)
1 user (show)

See Also:


Attachments
NetSetup.LOG from Windows Server 2008 RC 2 (14.49 KB, text/plain)
2010-04-27 04:20 UTC, David Adam
no flags Details
Level 10 log for client machine (IP address) (20.69 KB, text/plain)
2010-04-27 04:21 UTC, David Adam
no flags Details
Level 10 log for client machine (machine name) (698.72 KB, text/plain)
2010-04-27 04:21 UTC, David Adam
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Adam 2010-04-27 04:18:36 UTC
(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
Comment 1 David Adam 2010-04-27 04:20:07 UTC
Created attachment 5660 [details]
NetSetup.LOG from Windows Server 2008 RC 2
Comment 2 David Adam 2010-04-27 04:21:13 UTC
Created attachment 5661 [details]
Level 10 log for client machine (IP address)
Comment 3 David Adam 2010-04-27 04:21:38 UTC
Created attachment 5662 [details]
Level 10 log for client machine (machine name)
Comment 4 David Adam 2010-05-11 08:07:52 UTC
This still happens with Samba 3.5.2.
Comment 5 David Adam 2010-05-27 09:40:11 UTC
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.
Comment 6 David Adam 2010-05-29 12:06:10 UTC
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`.