When performing AD integration within an Active Directory 2008 environment, there are a couple of things to consider.
Please note that AD 2008 integration is fully supported V10 onwards.
AD 2008 or mixed environments
The one set of issues we have encountered was related to the settings “USE_DES_KEY_ONLY” and “DONT_REQUIRE_PREAUTH”. See as reference http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B305144 . I have seen these not set up properly in AD 2008 or in mixed environments. This usually shows up in scenarios where you have some users being able t o login and others don’t. In those cases the users are most likely in different KDC within a AD cluster with different settings.
Also, Windows had a bug that’s addressed in http://support.microsoft.com/?kbid=978055 (FIX: User accounts that use DES encryption for Kerberos authentication types cannot be authenticated in a Windows Server 2003 domain after a Windows Server 2008 R2 domain controller joins the domain)
Error “Invalid Username/Password or Disabled Account”, Kerberos encryption keys
Customer has set up Vontu v10 with AD authentication and is trying to login using the Vontu-Account/AD Password combination getting the standard error: “Invalid Username/Password or Disabled Account”.
In the log file we can see the following:
Thread: 13 INFO [com.vontu.enforce.authentication.kerberos.KerberosAuthenticationService] System property java.security.krb5.conf=/opt/Vontu/Protect/config/krb5.conf 06 Jan 2010 11:14:58,976- Thread: 13 INFO [com.vontu.enforce.authentication.kerberos.KerberosAuthenticationService] System property java.security.krb5.realm=/opt/Vontu/Protect/config/krb5.conf 06 Jan 2010 11:14:59,508- Thread: 13 INFO [com.vontu.manager.security.IpCatcherValve] Unsuccessful login attempt for user (XXX) at IP address: ..
Additionally, AD reports Event ID 4768
The default and common encryption settings that both Windows Kerberos and MIT Kerberos (Java implementation) supports are RC4-HMAC, DES-CBC-CRC and DES-CBC-MD5.
This is not a product defect, but some specific customization that the customer setup on his end or that got imposed due to other settings. The AD admin needs to point out what the required settings are and what the valid encryption settings are that allow proper communication. They may need to pay attention if they have the environment asymmetric setup, with multiple KDCs and clustered ADs. Modifying the KRB5.ini according to the following example might work, since it uses the default encryption methods:
Please note, this file is case sensitive. The realms must all be in CAPS where as kdc must be in lower case. If KDC is in upper case, kinit will fail.