After Badlock patch update unable to access Microsoft Active Directory.

Here are some additional hints how to work around the new stricter default behaviors:

• As an AD DC server, only Windows 2000 and Samba 3.6 and above as a domain member are supported out of the box. Other smb file servers as domain members are also fine out of the box.

• As an AD DC server, with default setting of "ldap server require strong auth", LDAP clients connecting over ldaps:// or START_TLS will be allowed to perform simple LDAP bind only.

  The preferred configuration for LDAP clients is to use SASL GSSAPI directly over ldap:// without using ldaps:// or START_TLS.

  To use LDAP with START_TLS and SASL GSSAPI (either Kerberos or NTLMSSP), sign/seal protection must be used by the client and server should be configured with "ldap server require strong auth = allow_sasl_over_tls".

  Consult OpenLDAP documentation how to set sign/seal protection in ldap.conf.

  For SSSD client configured with "id_provider = ad" or "id_provider = ldap" with "auth_provider = krb5", see sssd-ldap(5) manual for details on TLS session handling.

• As a File Server, compatibility with the Linux Kernel cifs client depends on which configuration options are selected. Please use "sec=krb5(i)" or "sec=ntlmssp(i)", not "sec=ntlmv2".

• As a file or printer client and as a domain member, out of the box compatibility with Samba less than 4.0 and other SMB/CIFS servers depends on support for SMB signing or SMB2 on the server, which is often disabled or absent. You may need to adjust the "client ipc signing" to "no" in these cases.

• In case of an upgrade from versions before 4.2.0, you might run into problems as a domain member. The out of the box compatibility with Samba 3.x domain controllers requires NETLOGON features only available in Samba 3.2 and above.

  However, a lot of these can be worked around by setting smb.conf options in Samba.

  You might run into a regression that will prevent users from trusted domains to be authenticated on a domain member server and related problems. You can indentify the bug by debug messages at log level 1 in log.wb-* similar to:

     Unwilling to make connection to domain OTHERDOMAIN without
     connection level security, must set "winbind sealed pipes = false"
     and "require strong key = false" to proceed: NT_STATUS_DOWNGRADE_DETECTED

• Note that there is a workaround by changing the configuration: The workaround consists in adding the following to the [global] section of the smb.conf on the domain member server. In the example you would have "workgroup = PRIMARYDOMAIN".

     winbind sealed pipes = false
     require strong key = false
     winbind sealed pipes:PRIMARYDOMAIN = true
     require strong key:PRIMARYDOMAIN = true

• For further information see https://bugzilla.samba.org/show_bug.cgi?id=11830

Between these changes, compatibility with a large number of older software versions has been lost in the default configuration.