|
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 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.