× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We are looking at the random password generators that people have to
carry with them at all times. New password every 60 seconds. I would
like to be able to do the fingerprint option but in addition to the
1,200 employees we also have 7,000 students. Any both of these groups
work from campus, from home and on the road. I can't provide fingerprint
readers at that volume. I think biometrics has reached the point where
PC manufactures should start including them on everything they make and
motherboard BIOS's setup to use them. In 5 years the majority of the PCs
in use would not have passwords to deal with. 

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, March 08, 2007 8:36 AM
To: Midrange Systems Technical Discussion
Subject: RE: password policy and system rules

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.