Configuring my System i for Kerberos authentication against two AD Domains
I spent a couple days this week attempting to get my two System I’s to authenticate against the AD domain we are going to. I thought it would be easy, but as with most things IBM it wasn’t. My biggest hurdle was getting the AS/400’s to talk AES to the new Windows 2008 R2 domains.
When we originally deployed Windows 7 in our current domain, I ran into this issue. We overcame it by using Group Policy to allow DES based encryption, which was all V5R4 would support at the time. This wasn’t a realistic option in the modern age.
The IBM Technote for Single Sign On lists 3 PTF’s that need to be installed (regardless of your current CUMPTF level). Each has its own hurdles:
SI44052 will load and temp apply, but what it doesn’t explicitly say unless you pay attention to the cover letters (RTFM!) is this requires an IPL to become effective. No big deal on our backup box, but I had to wait until the next scheduled IPL on production. The next two PTF’s depend on this one, so best install it first.
SI43034 will load and apply, but it requires you to reload all the TCP/IP jobs and a fair number of prestart jobs to enable it as well. I had to wait another day for production to take effect. SI43920 depends on this, and won’t install without it.
SI43920 will load and apply, but you can’t see the AES options in System i Navigator. Simply run the ‘Reconfigure’ option for Network Authentication Services to regenerate your keytabs with all the different key types, including AES.
Create forward and reverse DNS entries in the new domain (required for Kerberos).
Change the DNS host and domain information in GO TCP.
Delete all current information from EIM and NAS.
Reconfigured NAS on the new domain.
This one can be a bit tricky even with the handy batch file System i Navigator’s wizard creates. I recommend removing all the Windows 2000 stuff and only keep the DSADD, KTPASS, and SETSPN lines in the Windows 2003 section. Replace the ‘-pwd *’ and ‘-pass *’ with the AD domain account passwords, and remove the option that enforces DES.
Start up QSH and
Run ‘keytab list’ and verify you have AES keys listed. If not, something went wrong during the PTF’s.
Verify your new accounts work by running ‘kinit -k krbsvr400/[email protected]’ – if this fails make sure you read the error. I’ll try to add some troubleshooting later.
If the failure is simply a wrong password, test it by removing the ‘-k’ and enter the password it should be when prompted.
Also check that the ‘User cannot change password,’ ‘Password does not expire’ are checked and ‘User must change password at next login’ is unchecked, and the account is not locked out or disabled.
At this point, you can reconfigure EIM for the new domain and test it. I won’t do into the details as it’s in the technote.
Adding the second domain is a more manual
Add a second realm in NAS for the second AD domain.
In QShell, manually create your keytabs using ‘keytab add krbsvr400/[email protected] -p password’ format. You’ll need as many as you have setup for the other domain.
Test in the same manner as described above using kinit
Add a system registry in EIM pointing to the new Kerberos realm using the original as a template.
Add an identified to a test user and test access using a Kerberos based session on the new domain.
Troubleshooting for the second domain is exactly like the first.
