Re: more on Kerberos

Dang, forgot one more tip...

After using the the .BAT file produced by the wizard:

- comment out everything but the relevant ktpass command
- replace the hardcoded password in the ktpass command with "######"
or whatever you want
- Save the changed .BAT file

When it's time to change the password, replace "#######" with the new
password and run the .BAT file. This saves on typos...Then you can use the
QSH connand:
keytab add krbsvr400/yourco.ip.addr@xxxxxxxxxxxxxxxxxx -password
W3ThisIsNew

I don't know if IBM ever updated the iNav NAS GUI to allow password changes
for a specific entry. I don't have a system to test against right now.


On Fri, Mar 21, 2008 at 6:41 PM, Patrick Botz <pcbotz@xxxxxxxxx> wrote:

Yes there is -- at least with one assumption assumptions...

Assumption: You used a Windows user account (not a computer account) which
is what the .BAT file does

The only composition rules checked are the windows rules. This makes
sense when you understand Kerberos and that you are defining a kerberos
service principal to the Kerberos realm which is managed in AD. Naturally,
the passwords must meet the rules in the environment in which the
userID/service principal is defined. The entry in keytab files on remote
systems must match that entry.

When you want to change the password, change the password on the user
account first. If it is accepted, you know that the password meets the
rules. Then do the ktpass command. Of course, running ktpass again with the
new password (making sure to use "-mapop set") will fail also with some
message saying the password was not valid which tells you to try another
one.

Here are some tips for managing these passwords (once they are created):

- Always change the password on windows first (so you know if they
meet the windows password rules or not)
- I use the ktpass option to dump the keytab file (-dump arg I
believe), then ftp it to i5/OS in binary mode and overwrite the one in
/qibm/userdata/os400/networkauthentication/keytab/krb5.keytab (note that
path is from memory, could be wrong) rather than using the QSH keytab
commands
- The iNav Mgmt Central synchronize Network Authentication command,
I believe also updates the service principals password in AD.
- I use computer accounts rather than user accounts. It makes more
sense and there is no external password interface like there are for user
accounts. I do not believe the windows password composition rules are
applied to these passwords. For Windows clients participating in the domain,
MS automatically manages these passwords.
- I have a program that automates changing of passwords in i5/OS and
in Windows, and I just schedule it and forget it. Windows does not
automatically manage passwords for service principals representing "foreign"
computers (i.e. non-Windows clients). My company can provide this,
as is, for a one-time enterprise-wide charge.




On Fri, Mar 21, 2008 at 4:22 PM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
wrote:

Patrick Botz wrote:

One problem lots of folks tend to run into, is that they type a

trivial

password into the NAS config wizard. When they attempt to create the
Windows service principal (via the ktpass command on windows), they

get

a "password does not match" composition rules for the windows
environment. At this point, you have to use a password that meets the
windows rules -- but most importantly, you also have to go back and
change the password in the keytab file on i5/OS to match whatever new
password you provided on the ktpass command in windows.

This is a great point, Patrick. Is there an easy way to "test" a
password for composition rules? ktpass is not exactly the most
intuitive tool, at least for me.

Joe

--
Patrick Botz
VP, Security Consulting
Group8 Security, Inc.
pat.botz@xxxxxxxxxxxxxxxxxx
pcbotz@xxxxxxxxx
Office 507 285 9048
Cell 507 250 5644