Setting up Kerberos auth

[rcook]

I'm looking to configure ProfoundUI to work with Kerberos, but am having a problem. Everything works great using IBM i authentication, but as soon as I switch to Kerberos auth in the config file and restart the server I get a 404 error when I log in. The login page itself comes up fine, so the server's started, but trying to POST or navigate to /profoundui/atrium/menu just gives me a 404.

I don't know a whole lot about Kerberos and the documentation I found about activating it on Apache didn't seem to fit. I used http://www.profoundlogic.com/docs/display/PUI/Kerberos as a guide when changing the conf file, but am not sure where to go from here.

Any ideas? Is there something I missed?

Thanks.

[David]

This requires a lot more than the instructions on the page you referenced. Those instructions are valid, once Network Authentication is configured on your IBM i, but in order to configure Network Authentication requires much setup in IBM i, your Windows Server, and also sometimes network and DNS settings. Then on top of that you have to setup Enterprise Identity Mapping to map your Windows Active Directory users to IBM i users.

Has all that been done and working? Let me know if not, and I can point to an IBM Redbook and some useful articles on the topic. The idea is that once you have all this configured (which is quite a job), then you can use the directives mentioned in our doc page to tap into it. But the directives will not work for you without all of this prior setup.

Let me know.

[rcook]

According to the people who supposedly manage the servers it's all been set up on the backend, I just needed to enable it in ProfoundUI. I'm not sure if there are any logs or other sets of information to tell me if there's a bad config option somewhere in the kerberos chain (or even in ProfoundUI) so the 404 is the only thing I have to go on. Do you know what would cause that 404? I can probably work back from there, but I don't even know where to start.

[David]

Ok. If that is all setup on the backend and working, the instructions you found should be good.

A 404 error is 'page not found', meaning that Apache simply cannot map the URL you are typing to a resource on the server. A miscue between your URL and the mappings defined in the configuration somehow. It has to get passed this before it even has a resource to even try to authenticate you to, so this doesn't seem like a Kerberos-related problem (yet :-) ). I just wanted to bring up the needed backend config. to make sure we were not getting the cart before the horse.

What commenting/uncommenting those sections does is to:

1. Make all programs starting with PUI0003* (regardless of URL used to access them) use Kerberos authentication instead of IBM i profiles. These happen to be all Atrium programs.

2. Make all URLs starting with /profoundui/auth (regardless of what resource it actually is) use Kerberos authentication instead of IBM i profiles.

I'm not sure why this should give you a 404 if done as in those instructions, as these do not set the URL mappings. Those are done with the 'ScriptAlias' and 'Alias' directives in the file. So this is a bit confusing. The only way you should get a '404' when going to /profoundui/atrium/menu is if the ScriptAlias for that is missing, or points to a non-existent library/program.

Keep in mind that you will not want to come to the sign on page URL when using Kerberos. The sign on page is useless as with Kerberos the whole point is that you don't sign on. You get authenticated automatically by virtue of your being signed into the Windows domain. You'd want to come right to /profoundui/atrium/menu when using Kerberos, and you should get right in. If anything is wrong with authentication, I'd expect a '403' (not authorized) sort of message.

You can see more detail by looking in the Apache logs:

/www/HTTP_SERVER_INSTANCE_NAME/logs

The relevant error would be in the most recent log file -- they are named after the date created. Any clues in there?

[rcook]

I'm still looking into the 404 error, but I wanted clarify one of the points you made. You said that a user should skip the login page when using Kerberos authentication, but does that mean that the login page is essential disabled, or is it still available if a user is working remotely or otherwise not logged into the domain?

[Scott Klement]

If you use a URL with /profoundui/auth/start (or /profoundui/auth/genie, etc) then, once Kerberos is configured, it will attempt to use kerberos. If that's not available to remote users, it won't work.

However remote users should still be able to use the URL without the '/auth' added in. That should work the same as before.

[rcook]

Hmm, ok.

We currently launch all of our screens from the Atrium menu using /profoundui/auth/start to avoid having to register them. Once signed into Atirum (assuming a user is working remotely and isn't signed into the Kerberos domain), will the user be able to launch any of our programs? It sounds like this is going to be an issue; if so, is there a better way to launch programs so that kerberos-authenticated and remote users can use the same screens?

[David]

The HTTP server does have a 'use Kerberos if possible, fall back to HTTP Basic with IBM i profile' option for authentication...

See 'KerberosOrBasic' under AuthType directive here:

http://pic.dhe.ibm.com/infocenter/iseri ... d_core.htm

I've reviewed the processing, and it appears that Profound UI and Atrium 'should' work fine with this, but we have never tested it here, and have not had any customers using it, to my knowledge. I did not see any reason why it shouldn't work, however.

This is an oversimplification, of course, but Profound UI and Atrium generally just rely on the HTTP server for authentication and then just ask it who is the user. They don't really know or even care 'how' the user got signed in. So, looks like it would work, but of course there could be an unforeseen wrinkle, as it's not been used before.

Looking at the IBM doc, it would appear that you could simply change the value of our example 'AuthType' directive to 'KerberosOrBasic', and the value of the 'PasswdFile' directive to '%%SYSTEM%%' to achieve this setup.