Ersin Er wrote:
...
So where does the conversion occurs from clear text to KerberosKey
object. (I could learn this via a constructor usage search but I do
not have an environment here.)
BTW, SP and Triggers are core level constructs. So I do not think that
the clear text password reachs the core. But it's also a fact that
Kerberos service itself can update LDAP password to keep both
passwords in sync. So, adding an 'userPassword' update inside the
Kerberos service's operation chain should not be hard.
...
The Change Password Protocol is comprised of a single Chain of
Responsibility using a MINA IoHandlerChain called the
ChangePasswordChain. In the ChangePasswordChain is an IoHandlerCommand
"link" called ProcessPasswordChange. In ProcessPasswordChange the
plaintext password is converted to a KerberosKey and stored in the DIT.
So, you are correct that currently the plaintext password does not reach
the core. What I'm picturing is that 4 things change:
1) The Change Password protocol simply passes the plaintext password to
the core.
2) The core handles the conversion of the plaintext password to 1..n
key types. Right now Change Password only creates a DES key and the
intent was to not handle additional key types in the protocol provider,
but rather to wait for triggers/SP's in the core to do the 1..n
conversions based on configuration.
3) Password policy enforcement also moves to the core, for reuse by
other mechanisms for password changes. Password policy is currently
enforced in the CheckPasswordPolicy IoHandlerCommand. There is a major
issue here that rejected passwords would need to result in error
handling that results in the proper Change Password error being returned
to the client.
4) Looking further down the road, yet relevant to your access control
work, passwords should be modifiable according to access control. Users
need to be able to change their own password and, additionally, admins
with proper rights need to be able to initialize and change passwords, too.
Enrique
