Alex Tcherniakhovski - Security : AD Interop

Accessing ILM WMI Inteface from non-windows host

alextch — Fri, 09 Nov 2007 20:24:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

This screencast explores a scenario of calling WMI interface of ILM 2007 (MIIS component) from a non-Windows host, by utilizing Java.

Specifically middle-ware provided by Jintegra is utilized to access WMI from a Linux server.

This approach could be utilized when there is a requirement to remotely from a non-Windows host trigger functionality of ILM server exposed via WMI. In this screencast we will examine a scenario of calling setPassword method of MIIS_CsObject class in order to reset Active Directory Password from Linux via ILM.

Please, follow this link to see the screencast.

References:

Accessing Windows Management Instrumentation (WMI) from Java

Configuring DCOM for Remote Access

Mapping VB Code to Java Code

Shutting Down a Managed Windows Machine Using WMI in Java

J-Integra® Product Installation Instructions

Configuring Tomcat to authenticate against Active Directory

alextch — Tue, 26 Jun 2007 00:29:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

I quite often see application developers building their own authentication and authorization mechanisms into their applications. Of course, in some situations this approach may be required if the platform provided mechanisms are not meeting the requirements, but for the most part the built-in approach should be considered first for the following reasons:

1. Better security since access control is handled by the platform

2. Less code to write (let the platform do the work)

3. Ease of migration from one authentication source to another (no code changes required, only configuration file modifications)

4. Adherence to standards, which leads to possible SSO scenarios by utilizing Kerberos or Federation technologies

In this walkthrough I will demonstrate how to configure Apache Tomcat to utilize Active Directory for user authentication, and also how to leverage Active Directory groups for controlling access within Java applications.

Please, follow this link to see the walkthrough.

Resources:

Apache Tomcat Realm How-to

Sample Java application that retrieves group membership of an Active Directory user account.

alextch — Tue, 19 Jun 2007 00:45:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

This is a sample Java application that utilizes JNDI to access Active Directory and retrieves group membership of a user. This application uses computed tokenGroups attribute of a user object in order to get complete list of groups a user belongs to, including membership acquired through nested groups and built-in groups (ex. Domain Users).

Credits

There is almost no my code in this sample. I constructed this application by pulling together snippets from various posts on the Naming and Directory (JNDI) Forum , but since it took me a while to pull this all together I think there may be a value of having such useful sample all in one place.

Specifically I used the post (see link below) by Steven Adler. Steven also provided me with a function to convert binary value of a SID into its string representation. I needed this function since tokenGroups stores group SIDs in binary format.

http://forum.java.sun.com/thread.jspa?threadID=581444&tstart=150

package adconnection;

import java.util.Hashtable;
import javax.naming.*;
import javax.naming.ldap.*;
import javax.naming.directory.*;

public class memberof {
public static void main (String[] args) {

  Hashtable env = new Hashtable();
  String adminName = "CN=Administrator,CN=Users,DC=ADATUM,DC=COM";
  String adminPassword = "XXXXXXXXXXX";
  String ldapURL = "ldap://adfsaccount.adatum.com:389";
  env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
  //set security credentials, note using simple cleartext authentication
  env.put(Context.SECURITY_AUTHENTICATION,"simple");
  env.put(Context.SECURITY_PRINCIPAL,adminName);
  env.put(Context.SECURITY_CREDENTIALS,adminPassword);

  //connect to my domain controller
  env.put(Context.PROVIDER_URL,ldapURL);
  //specify attributes to be returned in binary format
  env.put("java.naming.ldap.attributes.binary","tokenGroups");

  try {

   //Create the initial directory context
   LdapContext ctx = new InitialLdapContext(env,null);

   //Create the search controls
   SearchControls userSearchCtls = new SearchControls();

   //Specify the search scope
   userSearchCtls.setSearchScope(SearchControls.OBJECT_SCOPE);

   //specify the LDAP search filter to find the user in question
   String userSearchFilter = "(objectClass=user)";

   //paceholder for an LDAP filter that will store SIDs of the groups the user belongs to
   StringBuffer groupsSearchFilter = new StringBuffer();
   groupsSearchFilter.append("(|");

   //Specify the Base for the search
   String userSearchBase = "CN=Alex Tcherni,CN=Users,DC=adatum,DC=com";

   //Specify the attributes to return
   String userReturnedAtts[]={"tokenGroups"};
   userSearchCtls.setReturningAttributes(userReturnedAtts);

   //Search for objects using the filter
   NamingEnumeration userAnswer = ctx.search(userSearchBase, userSearchFilter, userSearchCtls);

   //Loop through the search results
   while (userAnswer.hasMoreElements()) {

    SearchResult sr = (SearchResult)userAnswer.next();
    Attributes attrs = sr.getAttributes();

    if (attrs != null) {

     try {
      for (NamingEnumeration ae = attrs.getAll();ae.hasMore();) {
       Attribute attr = (Attribute)ae.next();
       for (NamingEnumeration e = attr.getAll();e.hasMore();) {

                                                            byte[] sid = (byte[])e.next();
                                                            groupsSearchFilter.append("(objectSid=" + binarySidToStringSid(sid) + ")");

       }
                                                        groupsSearchFilter.append(")");
      }

     }
     catch (NamingException e) {
      System.err.println("Problem listing membership: " + e);
     }
    }
   }


   // Search for groups the user belongs to in order to get their names
   //Create the search controls
   SearchControls groupsSearchCtls = new SearchControls();

   //Specify the search scope
   groupsSearchCtls.setSearchScope(SearchControls.SUBTREE_SCOPE);

   //Specify the Base for the search
   String groupsSearchBase = "DC=adatum,DC=com";

   //Specify the attributes to return
   String groupsReturnedAtts[]={"sAMAccountName"};
   groupsSearchCtls.setReturningAttributes(groupsReturnedAtts);

   //Search for objects using the filter
   NamingEnumeration groupsAnswer = ctx.search(groupsSearchBase, groupsSearchFilter.toString(), groupsSearchCtls);

    //Loop through the search results
   while (groupsAnswer.hasMoreElements()) {

    SearchResult sr = (SearchResult)groupsAnswer.next();
    Attributes attrs = sr.getAttributes();

    if (attrs != null) {
     System.out.println(attrs.get("sAMAccountName").get());
    }
   }

   ctx.close();

  }

  catch (NamingException e) {
   System.err.println("Problem searching directory: " + e);
           }
}


       public static final String binarySidToStringSid( byte[] SID ) {

    String strSID = "";

//convert the SID into string format

       long version;
       long authority;
       long count;
       long rid;

       strSID = "S";
       version = SID[0];
       strSID = strSID + "-" + Long.toString(version);
       authority = SID[4];

       for (int i = 0;i<4;i++) {
               authority <<= 8;
               authority += SID[4+i] & 0xFF;
       }

       strSID = strSID + "-" + Long.toString(authority);
       count = SID[2];
       count <<= 8;
       count += SID[1] & 0xFF;

for (int j=0;j<count;j++) {

rid = SID[11 + (j*4)] & 0xFF;

for (int k=1;k<4;k++) {

rid <<= 8;

rid += SID[11-k + (j*4)] & 0xFF;

}

strSID = strSID + "-" + Long.toString(rid);

}

       return strSID;

    }

}

Active Directory Schema Design Considerations and Auxiliary Classes

alextch — Wed, 16 May 2007 22:03:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

This blog addresses one very specific but important issue around rules of creating auxiliary classes, and as most of my blogs, is based on something I stumbled upon while working on one of my projects.
The scenario I am working on involves extending Active Directory schema for the purposes of storing Oracle related information in Active Directory. For more details on the approach of synchronizing AD and Oracle security information see my previous blog on this subject: http://blogs.msdn.com/alextch/archive/2006/06/05/ADtoOra.aspx
For the purposes of this discussion what is important is that we need to store additional information in the AD user class that pertains to Oracle specific attributes. The best practice around extending AD schema suggests creating an auxiliary class to store such information as opposed to modifying directly schema classes provided by Microsoft. The idea here is to create OracleSecurityPrincipal auxiliary class, which contains Oracle specific attributes and then later add this class as an auxiliary class to the User schema class. In this way we encapsulated all of the Oracle related information in a separate class but still have the ability to store these attributes in AD user object.
So I followed this guidance and created an LDIF import file that would create the required structure.
Below you can see an excerpt from that LDIF file.

dn: CN=codePlex-OraDefaultTableSpace,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
changetype: add
adminDisplayName: codePlex-OraDefaultTableSpace
attributeID: 1.2.840.113556.1.4.7000.159.24.10.66
attributeSyntax: 2.5.5.12
cn: codePlex-OraDefaultTableSpace
description: Specifies Oracle Default TableSpace
isMemberOfPartialAttributeSet: FALSE
isSingleValued: TRUE
lDAPDisplayName: codePlex-OraDefaultTableSpace
distinguishedName: CN=codePlex-OraDefaultTableSpace,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
objectClass: attributeSchema
oMSyntax: 64
name: codePlex-OraDefaultTableSpace
searchFlags: 0

dn: CN=codePlex-OraProfile,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
changetype: add
adminDisplayName: codePlex-OraProfile
attributeID: 1.2.840.113556.1.4.7000.159.24.10.68
attributeSyntax: 2.5.5.12
cn: codePlex-OraProfile
description: Specifies Oracle Profile Name
isMemberOfPartialAttributeSet: FALSE
isSingleValued: TRUE
lDAPDisplayName: codePlex-OraProfile
distinguishedName: CN=codePlex-OraProfile,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
objectClass: attributeSchema
oMSyntax: 64
name: codePlex-OraProfile
searchFlags: 0

DN:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=codePlex-OraSecurityPrincipal,CN=Schema,CN=Configuration,DC=Fabrikam,DC=msft
changetype: add
adminDisplayName: codePlex-OraSecurityPrincipal
description: adds Oracle related attributes to the user class
objectCategory: CN=Class-Schema,CN=Schema,CN=Configuration,DC=Fabrikam,DC=msft
objectClass: classSchema
lDAPDisplayName: codePlex-OraSecurityPrincipal
governsID: 1.2.840.113556.1.4.7000.159.24.10.611.11
instanceType: 4
objectClassCategory: 3
subClassOf: top
mustContain: codePlex-OraDefaultTableSpace
mayContain: codePlex-OraProfile

DN:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
changetype: ntdsSchemaModify
add: auxiliaryClass
auxiliaryClass: codePlex-OraSecurityPrincipal
-

DN:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

So let’s quickly walk through this LDIF file.
Firstly, we created several Oracle related attributes (there are many more required attributes, but I removed them to conserve space).
Secondly, an auxiliary schema class is created and the attributes created in step 1 are attached to it via mustContain and mayContain attributes of this class. We will come back to those two attributes shortly.
Thirdly, we add the auxiliary class created in step to 2 to the user schema object.

When I put together this LDIF file it seemed pretty logical to me, but when I ran this file against my test environment I got the following error message “Unwilling to perform. The server side error is 8505.” This error occurred while trying to add the OracleSecurityPrincipal auxiliary class into User structured class.

After conducting some research I realized that the issue was around the mandatory attributes defined as part of the auxiliary class via mustContain attribute. During addition of an auxiliary class AD checks if there are any existing objects of the structured class that we are modifying (in our case we are dealing with the User class, and of course any AD deployment would have existing user objects), but since I defined codePlex-oraDefaultTableSpace as a mandatory attribute, this would create an integrity issue within AD where some object that were created previously would be missing some mandatory attributes, and therefore AD refused this change.
So now that we understand the issue at hand, the only way to fix this issue is to make all of the auxiliary class attributes optional, by specifying them as mayContain.
mustContain: codePlex-OraDefaultTableSpace
mayContain: codePlex-OraProfile
Even though from the logic of the OracleSecurityPrincipal class the OraProfile attribute may be considered optional and OraDefaultTableSpace mandatory.
This was not intuitive to me at the beginning, but I suppose this is something that we need to keep in mind when working with auxiliary classes, especially if we plan to add them into the structured classes that already have objects in AD.

UNIX/LINUX Kerberos Authentication from the point of view of Windows Administrators

alextch — Tue, 01 Aug 2006 16:58:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

First small disclaimer: This blog is not intended to provide a reader with detailed knowledge of UNIX/LINUX authentication and authorization mechanisms, but rather aimed to highlight some points that may not be apparent to IT professionals whose background mainly involves working in Microsoft based environments.

Why should Windows Administrators care?

With the wide spread of Active Directory and increasing desire of IT managers to simplify their computing environments many companies are looking at ways to centralize authentication of Windows and UNIX users/hosts against a single directory. Since Active Directory natively supports such critical standards as Kerberos and LDAP and is widely used for authentication by Windows clients it is viewed as a natural choice for bringing other platforms (ex. UNIX/LINUX) under its umbrella.

By providing centralized source of authentication IT managers achieve single-sign-on environments between disparate platforms, reduce administrative overhead of managing multiple identities and position themselves better to meet audit requirements.

Having said that, more and more Active Directory administrators are now involved in tasks of integrating UNIX/LINUX into Active Directory environments, therefore some knowledge of UNIX/LINUX authentication and authorization mechanism may become a mandatory skill for a lot of Windows Administrators, hence this small article.

Differences in Kerberos implementations between Active Directory/Windows and MIT Kerberos/UNIX

Despite the fact that Kerberos is an industry standard protocol, its specifications allow for vendor extensions in order to improve its functionality. Microsoft has done a lot of work in making Kerberos an underpinning of Windows security infrastructure, and in doing so several protocol extensions were implemented, which were submitted as standards.

One of such extensions that is important for this discussion is PAC (Privilege Access Certificate). In the Microsoft implementation of Kerberos, a token issued by KDC contains information about user’s group membership, which allows for using Kerberos not only for authentication but also for authorization. The authorization is possible, since the service accepting a Kerberos token can determine from the group list in the PAC portion of the token whether access should be allowed to a resource based on ACL applied to the resource in question.

On the other hand, MIT implementation of Kerberos which is widely used in UNIX environments does not have such a facility, which limits the use of Kerberos only to authentication purposes. This is a very critical difference between Microsoft and MIT implementation which has some consequences on how UNIX/LINUX servers are configured in Kerberos environments. What does this really mean in terms of configuration? This may sound very strange for Windows Administrators: In a typical UNIX/LINUX environment a user is typically authenticated against one database (ex. Kerberos KDC database) and his or her account information (ex. UID, GID, group membership) is pulled from a different directory (ex. LDAP, NIS, local password files). In other words, when setting up a UNIX/LINUX box two separate configuration tasks need to be performed: authentication and authorization. We will explore these UNIX/LINUX facilities in the next two sections. Of course, in Active Directory environment authentication and authorization information is stored in one place, which greatly simplifies administration and also improves performance since Kerberos has access to authorization data and packs it into the issued tokens, whereas in UNIX/LINUX environments additional network queries need to be performed outside Kerberos exchange to determine authorization attributes of a user.

What is PAM?

PAM stands for Pluggable Authentication Module, and is an API that allows the system administrator to configure authentication mechanisms rather than having authentication mechanisms hardcoded into the application. PAM is supported on Linux, HP-UX, AIX 5.1 and above, and Solaris. Administrators can customize an application's authentication system by making changes to /etc/pam.conf or an application specific file in the /etc/pam.d/ directory.

PAM modules are shared libraries that add support for a specific authentication mechanism. UNIX platforms that support PAM normally have a PAM module called pam_unix for standard UNIX local file authentication.

So from a perspective of a Windows Administrator how is PAM different let’s say from Windows GINA?

By using PAM different applications can be configured to use different authentication sources. For example gdm (Gnome graphical login) could be configured to use MIT Kerberos pam_krb5 module, and let’s say telnet could be configured to use local UNIX password files pam_unix. Again, this quite different from a typical Windows environment where a user is typically authenticated once during login and against a single source. Obviously, this is a very important point to keep in mind when configuring a UNIX/LINUX box to authenticate against Active Directory. You need to ensure that all applications in question (ex. Graphical login, telnet, ssh, rlogin) are configured to authenticate against Active Directory.
An application could be configured to authenticate against multiple sources. In other words, authentication could be chained. For example, graphical login could be configured to first try local UNIX password file, then MIT Kerberos, then NIS, and only then Active Directory. Obviously, we need to pay special attention to the sequence in which those authentication sources are configured, since you may get unexpected results if, for example, a user account with which you are logging-in is first found in local UNIX file, but really you meant to authenticate against Active Directory. So pay attention to the order of authentication sequence. If AD is the primary source of authentication, then move it to the beginning of the pam configuration file for the application in question.
Within PAM paradigm it is possible to require for multiple authentication sources to succeed in order to allow user to gain access to an application. This is something that Windows Administrators are not really accustomed to, therefore carefully examine the pam configuration files, especially for the authentication sources marked as required, and ensure that nothing blocks a user from accessing an application if he or she is successfully authenticated against AD, of course unless your intentions are to require additional authentication on top of AD. We will examine a sample PAM configuration file later on in this document in order to provide you with a practical example.

What is NSS?

UNIX/LINUX operating systems use various “databases” to obtain information about users, groups and so forth. Traditionally, these databases were stored as flat text files in the /etc directory. For example, user information is stored in /etc/passwd and group information is stored in /etc/group. The Name Service Switch (NSS) is a subsystem built directly into the C runtime library (libc) and allows user and group identity information to be obtained from a variety of backend sources—not just the text files in the /etc directory. System administrators can change the NSS configuration by modifying the /etc/nsswitch.conf file. NSS modules are shared libraries that add support for user and group identity information to be retrieved from a specific backend data source. Common NSS modules are for nis, files, and db backends.

NSS is probably a completely new concept for a Windows Administrator. Since authorization data is packaged into Kerberos tokens, Windows Administrators usually do not need to perform tasks around retrieval of authorization data. I myself was initially caught by surprise when configuring a LINUX workstation for authentication against AD. After I completed configuration of pam modules for AD, I tried to login to the workstation by providing my AD credentials, but was not able to pass through login screen. I examined the logs and saw messages about successful authentication, so why I could not login? Well, after examining the logs further I saw a message about unsuccessful attempt to retrieve my account information (at that point I did not properly configure nssswitch.conf yet). That was a very good lesson which made me realize that login process on UNIX/LINUX consists of two completely separate processes: authentication and user information retrieval. Both processes need to succeed in order to login. Another probably strange thing, from a Windows Administrator point of view, is the fact that authentication information and user account information are typically stored in separate databases, in contrast to AD where everything is stored in a single database.

Configuration Example: Vintela Authentication Services

So let’s walk through a configuration example that should outline some of the concepts that we discussed in the article. In this example we will examine a configuration of LINUX workstation configured to authenticate against Active Directory. For the purposes of this example I will use Vintela Authentication (VAS) Services package, provided by Quest, which allows seamless integration of UNIX/LINUX operating systems with AD. This example assumes that VAS is already installed and configured.

For details on VAS see this link: http://www.quest.com/Vintela_Authentication_Services/

As an example we will take a look at configuring Gnome Graphical Login (GDM) to use AD as authentication source. So by switching to the /etc/pam.d directory and editing gdm file as shown below we will configure this application to among other things authenticate against AD.

auth [ignore=ignore success=done default=die] pam_vas3.so create_homedir get_tgt

auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok

auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass

auth required /lib/security/$ISA/pam_deny.so

account [ignore=ignore success=done default=die] pam_vas3.so

account required /lib/security/$ISA/pam_unix.so broken_shadow

account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet

account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_krb5.so

account required /lib/security/$ISA/pam_permit.so

password [ignore=ignore success=done default=die] pam_vas3.so

password requisite /lib/security/$ISA/pam_cracklib.so retry=3

password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow

password sufficient /lib/security/$ISA/pam_krb5.so use_authtok

password required /lib/security/$ISA/pam_deny.so

So let’s attempt to decipher this configuration file.

First of all, you will notice that the file is divided into three sections: auth, account and password.

auth – In this section we configure pam module’s sequence and parameters for performing validation of submitted user names and passwords

account – In this section we configure pam module’s sequence and parameters for performing account validation (account againg, expiration, etc)

password - In this section we configure pam module’s sequence and parameters with respect to dealing with password policies

Now let’s walk through the auth section. There are four pam modules specified there, and as explained earlier their sequence is important. So in our case VAS module will have precedence over all other modules, therefore user credentials will be first checked against AD. If credentials are validated successfully then no other pam modules in the auth section will be invoked (success=done assures us of that). You need to consult the VAS documentation to fully understand all options available to you when configuring this module (by the way, the same is true for any other pam module).

Should AD authentication fail, then pam_unix (local UNIX password file) will be tried, should this pam fail as well then pam_krb5 (MIT Kerberos implementation) will be tried. If none of the first 3 pam modules succeed then pam_deny will force login failure.

The remaining account and password sections are almost identical to auth section, therefore will not be discussed here.

Now let’s take a look at nsswitch.conf configuration file. To conserve space I only provide the relevant portion of the file here.

passwd: files vas3

shadow: files

group: files vas3

As you can see, this file is quite simple. It simply lists the order in which the system will attempt to gather user account information. For example, for a given user the system will first try to determine his or her group membership by looking at /etc/passwd identified by files keyword and then if that fails will switch to VAS, which it turn uses AD as a source of group membership.

How to establish two-way trust relationship between MIT V5 Kerberos Realm and Active Directory using RC4 encryption

alextch — Tue, 18 Jul 2006 22:59:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

With the introduction of Windows 2003 SP1 it is now possible to use RC4 encryption for Kerberos exchanges between MIT V5 Realms and Active Directory as opposed, now considered to be week, DES protocol. Despite the fact that there a several good resource on the web that provide sufficient information on how to in principal establish trust between AD and MIT V5 Kerberos Realm, most of them were written prior to Windows 2003 SP1 and do not provide information on how to utilize RC4.

This walk-through attempts to bridge this gap and provide some specifics as to how to configure the trust to use RC4 encryption.

Please, follow this link for the complete walkthrough.

How to interpret encryption types definitions in krb5kdc.log on UNIX KDC, during configuration of trust relationship between MIT V5 Realm and Active Directory

alextch — Tue, 18 Jul 2006 19:06:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

First of all why this is even important? Well, if you ever tried to configure a trust relationship between MIT V5 Realm and AD, I am sure you probably ran into some initial configuration issues and had to look into the krb5kdc.log file to figure out what the issue was. Basically a very typical issue to run into is the fact that AD and MIT Realm could not agree on mutual encryption types and krb5kdc is a good place to find out about this. Additionally, with introduction of Windows 2003 SP1 it is now possible to use RC4 encryption for Kerberos exchanges between MIT V5 Realms and Active Directory as opposed, now considered to be week, DES protocol. So by looking at the krb5kdc.log you can see what type of encryption is being used to ensure that RC4 is in fact being utilized. One of the problems that I encountered during such troubleshooting sessions was the fact that encryption types displayed in the log file are not presented in an intuitive format.

Let’s take a look at a sample log entry from krb5kdc.log:

Jul 17 11:19:57 rh01.mit.contoso.com krb5kdc[1864](info): TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 192.168.15.103: ISSUE: authtime 1153149597, etypes {rep= 23 tkt=23 ses=23}, j...@MIT.CONTOSO.COM for krbtgt/MIT.CONTOSO....@MIT.CONTOSO.COM

Let’s try to decipher this message. So first of all this is a TGS_REQ packet (client is requesting TGT) from client at IP 192.168.15.103. The client in the TGS_REQ is sending the encryption types that it supports in the following structure etypes {23 -133 -128 3 1 24 -135}. If you thought that the numbers in brackets represent corresponding encryption types then you are correct. The challenge for me was to find the translation from numbers to actual protocol names so that this message could have some meaning. After doing some digging and posting, I finally found that the translation table is defined in RFC 3961 Section 8 http://www.ietf.org/rfc/rfc3961.txt. For your convenience I pasted the table here as well.

encryption type                etype      section or comment

      -----------------------------------------------------------------

      des-cbc-crc                        1             6.2.3

      des-cbc-md4                        2             6.2.2

      des-cbc-md5                        3             6.2.1

      [reserved]                         4

      des3-cbc-md5                       5

      [reserved]                         6

      des3-cbc-sha1                      7

      dsaWithSHA1-CmsOID                 9           (pkinit)

      md5WithRSAEncryption-CmsOID       10           (pkinit)

      sha1WithRSAEncryption-CmsOID      11           (pkinit)

      rc2CBC-EnvOID                     12           (pkinit)

      rsaEncryption-EnvOID              13   (pkinit from PKCS#1 v1.5)

      rsaES-OAEP-ENV-OID                14   (pkinit from PKCS#1 v2.0)

      des-ede3-cbc-Env-OID              15           (pkinit)

      des3-cbc-sha1-kd                  16              6.3

      aes128-cts-hmac-sha1-96           17          [KRB5-AES]

      aes256-cts-hmac-sha1-96           18          [KRB5-AES]

      rc4-hmac                          23          (Microsoft)

      rc4-hmac-exp                      24          (Microsoft)

      subkey-keymaterial                65     (opaque; PacketCable)

So now we can see that the client requested etypes {RC4-hmac -133 -128 des-cbc-md5 des-cbc-crc RC4-hmac-exp -135}. A bit clearer, but what about those negative values? Well negative values are reserved to implementers of protocol. Since the client in my case was XP workstation, then the negative values would be defined by Microsoft, and indeed in Microsoft Windows Platform SDK ntsecapi.h we can find:

#define KERB_ETYPE_RC4_MD4 -128 // FFFFFF80
#define KERB_ETYPE_RC4_PLAIN2 -129
#define KERB_ETYPE_RC4_LM -130
#define KERB_ETYPE_RC4_SHA -131
#define KERB_ETYPE_DES_PLAIN -132
#define KERB_ETYPE_RC4_HMAC_OLD -133 // FFFFFF7B
#define KERB_ETYPE_RC4_PLAIN_OLD -134
#define KERB_ETYPE_RC4_HMAC_OLD_EXP -135
#define KERB_ETYPE_RC4_PLAIN_OLD_EXP -136
#define KERB_ETYPE_RC4_PLAIN -140
#define KERB_ETYPE_RC4_PLAIN_EXP -141

So now using those 2 sources we can completely interpret the message as:

{RC4-HMAC RC4-HMAC-OLD RC4-MD4 DES-CBC-MD5 DES-CBC-CRC RC4-HMAC-EXP RC4-HMAC_OLD_EXP}. By the way the token was issued with etype = 23 which means RC4-HMAC, which is exactly what you want.

Active Directory and UNIX integration via Vintela line of products

alextch — Thu, 03 Nov 2005 22:21:00 GMT

Active Directory and UNIX integration via Vintela line of products

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Please, follow this link to see a demo on integration capabilities (SSO, Management) between Active Directory and UNIX using Vintela line of products (VAS, VGP, VMX)

How to set Active Directory Password from Java application

alextch — Wed, 15 Jun 2005 22:50:00 GMT

How to set Active Directory Password from Java application

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Business Scenario

Many Java applications now utilize Active Directory as a source of authentication, in some situations it may be required to set Active Directory password from within Java applications. I encountered a scenario where majority of the users of a Java application were on Active Directory, but for a small percentage of users that do not log-in to Active Directory from their desktops we needed to provide a functionality within the application to set user passwords.

Please, follow this link for a complete step-by-step guide