NT ADS Join from Samba 3.6.6+ to Windows Server 2008 ADS fails with ACCESS_DENIED?

[Michael DePaulo]

Wait, according to the descriptions of those registry keys on
technet.microsoft.com, you needed to set "client ldap sasl wrapping" to
"seal", not "sign".


On Mon, Apr 22, 2013 at 10:17 AM, Michael DePaulo <mikedep333 at gmail.com>wrote:

> Actually, it sounds like your customer manually enabled 1 or more of the
> group policy settings to require digital signatures of network traffic, and
> that's why the reg keys were set. I looked through the "Group Policy
> Settings Reference" spreadsheet available on microsoft.com, and I think
> these are all the signing-related settings on server 2008 R2. It was
> probably the LDAP settings that affected you:
>   Computer Configuration\Windows Settings\Local Policies\Security Options
> Domain controller: LDAP server signing requirements  Computer
> Configuration\Windows Settings\Local Policies\Security Options Domain
> member: Digitally encrypt or sign secure channel data (always)  Computer
> Configuration\Windows Settings\Local Policies\Security Options Domain
> member: Digitally sign secure channel data (when possible)   Computer
> Configuration\Windows Settings\Local Policies\Security Options Microsoft
> network client: Digitally sign communications (always)  Computer
> Configuration\Windows Settings\Local Policies\Security Options Microsoft
> network client: Digitally sign communications (if server agrees)   Computer
> Configuration\Windows Settings\Local Policies\Security Options Microsoft
> network server: Digitally sign communications (always)  Computer
> Configuration\Windows Settings\Local Policies\Security Options Microsoft
> network server: Digitally sign communications (if client agrees)  Computer
> Configuration\Windows Settings\Local Policies\Security Options Network
> security: LDAP client signing requirements
>
>
> Samba's smb.conf has similar digital signature options.I looked through
> the manpage for smb.conf, I think they are:
> client ldap sasl wrapping (G)
> client signing (G)
> server signing (G)
>
> So I am fairly certain that changing "client ldap sasl wrapping" from the
> default 3.6.6 value of "plain" to "sign" would have solved your problem
> without you having to modify server-side reg keys.
>
>
> On Mon, Apr 22, 2013 at 9:46 AM, Richard Sharpe <
> realrichardsharpe at gmail.com> wrote:
>
>> On Mon, Apr 22, 2013 at 12:40 AM, Andrej Pintar <api984 at gmail.com> wrote:
>> > Richard Sharpe <realrichardsharpe <at> gmail.com> writes:
>> >
>> >>
>> >> Hi folks,
>> >>
>> >> We are seeing a Samba 3.6.6+ installation when trying to join a Server
>> >> 2008 ADS domain fail with ACCESS DENIED.
>> >>
>> >> We use 'net ads join' and see the following during the join process:
>> >>
>> >> SPNEGO login failed: Access denied
>> >> failed session setup with NT_STATUS_ACCESS_DENIED
>> >>
>> >> The command seems to only be prepared to use NTLMSSP rather than KRB5.
>> >>
>> >> Is there some policy setting in ADS that enforces KRB5 authentication?
>> >> Can they require that the older RPCs not be used?
>> >>
>> >
>> > Took me 3 weeks to find what it was.
>> >
>> > You need to change 2 reg keys in NETLOGON service to make those ACCESS
>> DENY
>> > go away. You can also test with rpcclient a samlogon function to see if
>> it
>> > works ok.
>>
>> This is awesome. Thatnk you very much. Now we can test and see why it
>> fails when it succeeds for Windows.
>>
>> > I was using ADS security. This fixed all samba versions. 3.0.33 3.6.6.
>> and
>> > 4.0.0. Just to say none of them worked when i tested.
>> >
>> > Netlogon service:
>> >
>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
>> > "DisablePasswordChange"=dword:00000000
>> > "maximumpasswordage"=dword:0000001e
>> > "requiresignorseal"=dword:00000001
>> > "requirestrongkey"=dword:00000000 <- this
>> > "sealsecurechannel"=dword:00000001 <- this
>> > "signsecurechannel"=dword:00000001 <- this (this was missing i think
>> > when i changed it)
>> > "Update"="no"
>> > "SysvolReady"=dword:00000001 <- added also
>> > "SysVol"="C:\\WINDOWS\\SYSVOL\\sysvol"
>> >
>> > This should make it work.
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Regards,
>> Richard Sharpe
>> (何以解憂？唯有杜康。--曹操)
>>
>
>