Changing user password in Active Directory using the JNDI GSS-API/Kerberos5

Question

Hello,
I am trying to the JNDI GSS-API to change a user password on an Active Directory Server 2003. I have seen a variation of this using SSL on the thread [*http://forums.sun.com/thread.jspa?threadID=592611&start=0&tstart=0*|http://forums.sun.com/thread.jspa?threadID=592611&start=0&tstart=0]
but I can't seem to make this work using the GSS-API. I can successfully create a javax.security.auth.login.LoginContext.LoginContext and then call the login method on it to log in as a user. I then call the javax.security.auth.Subject.doAs() method which calls the run method in a class extending the javax.security.PrivilegedActionClass. But when I actually try to change the password using InitialDirContext.modifyAttributes(), I get the exception:
*javax.naming.OperationNotSupportedException: [LDAP: error code 53 - 00002077: SvcErr: DSID-03190DC9, problem 5003 (WILL_NOT_PERFORM), data 0*
*If anyone can help me figure out why it doesn't work, that would be great!*
P.S: I know the error seems to suggest that there might be some active directory setting that is preventing this from working, but I've checked all relevant settings on the Windows 2003 server Active Directory that I can think of: In the User properties->Account->Account options, I've made sure the user can change password. Also, in the Group Policy->Computer Configuration->Windows Settings->Security Settings->Account Policies->Password Policy, Maximum password age is zero and so is minimum password age.
Here's my java code:
{code}import javax.naming.*;
import javax.security.auth.*;
import java.security.PrivilegedAction;
import java.io.UnsupportedEncodingException;
public void changeSecret((String uid, String oldPassword, String newPassword)
     throws NamingException, ACException{
try {
     K5CallbackHandler cb = new K5CallbackHandler(uid, oldPassword);
     LoginContext lc = new LoginContext("marker", cb);
     lc.login();
     Subject.doAs(lc.getSubject(), new ChangePasswordAction(rz.getName(), oldPassword, newPassword));
     catch(LoginException e) {
     try {
          lc.logout();
     catch(LoginException e) {
}ChangePasswordAction.java is:import javax.naming.*;
import javax.naming.naming.directory.*;
import java.io.UnsupportedEncodingException;
private class ChangePasswordAction implements PrivilegedAction {
     private String uid;
     private String quotedOldPassword;
     private String quotedNewPassword;
     public ChangePasswordAction(String uid, String oldPassword, String newPassword) {
          this.uid = uid;
          quotedOldPassword = "\"" + oldPassword + "\"";
          quotedNewPassword = "\"" + newPassword + "\"";
     public Object run() {
          Hashtable env = new Hashtable(11);
          env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
          env.put(Context.PROVIDER_URL, "ldap://ad2k3:389");
          env.put(Context.SECURITY_AUTHENTICATION, "GSSAPI");
          try {
               DirContext ctx = new InitialDirContext(env);
               ModificationItem[] mods = new ModificationItem[2];
               byte[] oldPasswordUnicode = quotedOldPassword.getBytes("UTF-16LE");
               byte[] newPasswordUnicode = quotedNewPassword.getBytes("UTF-16LE");
               mods[0] = new ModificationItem(DirContext.REMOVE_ATTRIBUTE, new BasicAttribute("unicodePwd", oldPasswordUnicode));
               mods[1] = new ModificationItem(DirContext.ADD_ATTRIBUTE, new BasicAttribute("unicodePwd", newPasswordUnicode));
               ctx.modifyAttributes(uid, mods);
               ctx.close();
          } catch (NamingException e) {
          } catch (UnsupportedEncodingException e) {
          return null;
}K5CallbackHandler is:import javax.security.auth.callback.*;
final class K5CallbackHandler
implements CallbackHandler {
     private final String name;
     private final char[] passwd;
     public K5CallbackHandler(String nm, String pw) {
          name = nm;
          if(pw == null) {
               passwd = new char[0];
          else {
               passwd = pw.toCharArray();
     public void handle(Callback[] callbacks)
     throws java.io.IOException, UnsupportedCallbackException {
          for(int i = 0; i < callbacks.length; i++) {
               if(callbacks[i] instanceof NameCallback) {
                    NameCallback cb = (NameCallback) callbacks;
                    cb.setName(name);
               else {
                    if(callbacks[i] instanceof PasswordCallback) {
                         PasswordCallback cb = (PasswordCallback) callbacks[i];
                         cb.setPassword(passwd);
                    else {
                         throw new UnsupportedCallbackException(callbacks[i]);
}The relevant entry in the JAAS.conf file that is referred to as "marker" in the LoginContext constructor is:
marker {
com.sun.security.auth.module.Krb5LoginModule required client=TRUE;

Answer 1

This is one of the two Active Directory operations I have never solved using Java/JNDI. (FYI the other one is Cross Domain Move).
My gut feel is that the underlying problem (which happens to be common to both Change Password & X-Domain Move) is that Java/JNDI/GSSAPI does not negotiate a sufficiently strong key length that allows Active Directory to change passwords or perform cross domain moves when using Kerberos & GSSAPI.
Active Directory requires at a minimum, 128 bit key lengths for these security related operations.
In more recent Kerberos suites and Java versions, support for RC4-HMAC & AES has been introduced, so it may be possible that you can negotiate a suitably string key length.
Make sure that your Kerberos configuration is using either RC4-HMAC or AES and that Java is requesting a strong level of protection. (You can do this by adding //Specify the quality of protection
//Eg. auth-conf; confidentiality, auth-int; integrity
//confidentiality is required to set a password
env.put("javax.security.sasl.qop","auth-conf");
//require high strength 128 bit crypto
env.put("javax.security.sasl.strength","high"); in your ChangePasswordAction class.
You may also want to enable sasl logging in your app to see what exactly is going on and you may also want to check on the Java Security forum how to configure/enforce/check both RC4-HMAC or AES is used as the Kerbeos cipher suite and that a string key length is being used.
Good luck.