RE: password policy and system rules -- MIDRANGE-L

Screw all this complication.  Do what we are rolling out.  We bought some 
software that plugs into active directory.  Now you can only sign on using 
your fingerprint.  Yes there is a password, for internal use only.  It's 
set by the software to be totally random and no user or administrator can 
look at it.  Then we set up Kerberos, or EIM (Enterprise Identity Mapping) 
on our i5.  An active directory user, let's say "smitty", logs on to his 
PC.  The relation set up in EIM in iNav says that "smitty" in Active 
Directory is JOHNS on the i5.  We ran a
CHGUSRPRF USRPRF(JOHNS) LCLPWDMGT(*NO)
on the i5.  In iNav, on the users pc, we told the connection to use 
Kerberos.  We set up all their 5250 sessions to bypass sign on.  If they 
log off and get a sign on screen they are screwed.  They cannot sign on to 
a plain 5250 screen.  They would have to disconnect the session and 
reconnect so that it would bypass the signon screen.

The only people we won't run the LCLPWDMGT(*NO) on is systems people that 
currently log on to an HMC, or may use one of the two twinax terminals for 
the two 270's that are on the list to be replaced.

Finding it hard to get funding, or management support for such an 
endeavor?  Get an audit scheduled for your medical division.  I don't know 
if it was a customer or what but they insisted on biometrics.

We muddled through it ourselves.  And use the i5 to store the Kerberos 
stuff.  INav could use some improvements.  Namely when you do a lookup it 
won't search the source (active directory) or the target (i5/os) user ids, 
but it only searches records you have already entered in EIM.  Search is 
worthless as t!ts on a boar hog.  Submitted a DCR on this.  Looked at 
software that will do this and heavily supports the i.  However I figured 
our operator can enter these and we can tolerate an occasional mistake 
versus paying $15 an entry for the software.

How does this play in a Mimix environment?  When I switch over from one i5 
(that's running Kerberos) over to the other i5 (that should be running 
Kerberos) are we affected?  Will it work?  Frankly, Lakeview is scratching 
their heads on this one.  They have a switch planned for this weekend for 
another customer that is using EIM and are supposed to be closely 
monitoring that.
Prompt CHGUSRPRF.  Roll down to the bottom.  See EIMASSOC?  You won't see 
that on DSPUSRPRF.  The help basically says that it's not stored in the 
user profile itself, restoring user profiles won't recover this and we 
won't tell you where it is.  Also, I'd like to know where the EIM domains, 
and associations, are that you set up in iNav.  Well, the associations are 
probably in the same place that CHGUSRPRF accesses.

Hey Al Barsa.  You're a save/restore kind of person, and a Mimix peddler. 
If you hear anything, let me know.

I wonder if Pat Botz (Single sign on God at IBM) wrote a whitepaper 
covering "Single Sign On in a High Availability environment" or 
"Save/Restore considerations for Single Sign On".

Rob Berendt