Re: Setting up single sign on in a windows domain

Agreed = at least in the principle that one needs a back-door for security officers, etc. And that those who benefit most are users. But help desk personnel also have less to do with resetting passwords and all that - estimates range all over but 40% is often cited as the time used in that help desk activity.

Nonetheless, Kerberos (Network Authentication Service is IBM's name for it, since MIT does not allow use of Kerberos in a product name) support is available for the Apache web server and works with jt400 - all you need is the system name when creating an AS400 object with jt400 - very cool! And SSO support is available for Netserver - oh yeah, and LDAP.

I enabled one of our applications for Kerberos authentication - it's very cool! Of course, I'm a guy who still gets a kick out of learning new stuff.

SSO on i also includes setting EIM - Enterprise Identity Mapping - the whole thing has no password caches - that's all done on the Active Directory server. BTW, Windows authentication is Kerberos, too. An interesting thought as I write - Windows users can log in locally if the AD server goes down and often still get some work done. I know, there are probably all kinds of wrongness about that statement that I'm not aware of!

I think SSO using Kerberos and EIM can be a great solution to decrease cost in a company - often due to managing passwords being drastically reduced. APIs are available for you to roll your own app enablement. EIM let us map windows users to our application users. With jt400 you have so many options for client apps. It's a good time to be on IBM i!

Regards
Vern

On 8/2/2012 7:22 AM, Charles Wilt wrote:

IMHO...

SSO is for normal users...

Delveopers and Admins and maybe Operators will probably want to stay
with non-SSO...or at least have two accounts perhaps...

Charles

On Wed, Aug 1, 2012 at 9:09 PM, Matt Olson <Matt.Olson@xxxxxxxx> wrote:

Be careful with the single sign on, several of IBM's own products don't even support Kerberos (SSO) in them, so when you enable SSO on your AS400 account your out of luck getting in without creating another non-SSO enabled login account which defeats the whole purpose of SSO.

A perfect example is Rational Developer for Power Systems, AKA RDP, AKA RDi, aka a bunch of other names.

________________________________________
From: Vernon Hamberg [vhamberg@xxxxxxxxxxxxxxx]
Sent: Wednesday, August 01, 2012 2:31 PM
To: Midrange Systems Technical Discussion
Subject: Re: Setting up single sign on in a windows domain

Darryl

IBM actually has a fair amount of material on this. There is a
comprehensive Redbook on this. It's not necessarily for the faint of
heart, but it's doable. There are things in infocenter, as well, but in
my experience, all of it makes assumptions about what you know - it was
very frustrating at first glance.

But recently the ISV support team in Rochester published an SSO 101
article on developerworks - that is at this URL -

http://www.ibm.com/developerworks/ibmi/library/i-sso/index.html

They were immensely helpful to me in enabling single sign-on in one of
our products.

There is a link to the Redbook in the developerworks article.

You WILL need to get with your Windows domain administrator. One of the
prerequisites is that you are signed in to a Windows domain, not your
local Windows box.

HTH
Vern

On 8/1/2012 9:30 AM, Darryl Freinkel wrote:

I would like to set up single sign on on my network and need some help as I
am not a windows administrator and need to know how to configure the system
to work with the windows domain. IBM does not provide help to configure the
systems to Microsoft products.

Can someone help me with guidelines or examples of configuring my i to the
domain?

TIA

Darryl Freinkel

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.