This is what I was thinking.   I believe I can require my admin users to 
use a particular port on the TN3270 server task and assign a unique set of 
LUs that way.  Non-admin users would not have access to that port.  If a 
user connects to the open port, they would wind up with an LU that would 
not be eligible for admin sign-on, so a non-admin user that somehow gets 
an admin's RACF userid and password would not get anywhere easily.  The 
sticky part is finding that LU for the RACF exit.   We'll see how that 
goes. 

Express Logon Feature is attractive, if I can't manage what I'm thinking, 
what I'd need to be able to do is require the function for admin users, so 
they'd have to pass a cert to log on and knowing the RACF password 
wouldn't get it done. 

Then there are all the operational issues, such as how to grant access 
when my brilliant schemes break. 

Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433





From:   Charles Mills <charl...@mcn.org>
To:     IBM-MAIN@LISTSERV.UA.EDU
Date:   12/04/2012 17:27
Subject:        Re: Correlating workstation userid to TN3270 logon using 
client certificates
Sent by:        IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



I am not an expert on your exact question but I have done a lot with SSL
certificates and with SMF data from RACF and from TCP/IP. I think RACF is
pretty far removed from your TCP/IP sign-on, because TN3270 sits in the
middle. As far as RACF is concerned, your client didn't sign on, a virtual
terminal owned by TN3270 signed on.

You would have to capture it from TCP/IP somehow and hand it off to your
RACF exit.

Not an entire answer, but I hope this helps.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tom Ambros
Sent: Tuesday, December 04, 2012 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Correlating workstation userid to TN3270 logon using client
certificates

I apologize if this has been covered already, but I probably need to tell
somebody if this can be done before I read up and put the pieces together. 



If I have an SSL-capable emulator, is it possible to validate the client 
certificate and extract the userid (this part, at least, I know can be 
done) and somehow persistently store it so that  the RACF logon exits can 
locate it and verify that the userid entered at the application logon 
screen is the same userid that was presented in the client certificate? 

There are two factor authentication products that work at RACF logon but 
they have their drawbacks, we're musing about the possibility of fitting 
in with some of the distributed schemes for consistency's sake and closing 

the gap where one can get on a workstation with one set of credentials and 

then use another set that fell off the back of a truck to have a good old 
time in ways that may be distasteful to some.   The distributed schemes 
involve seemingly robust what I have and what I know type processes and if 

we can then implement something reasonably inobtrusive on zOS we'd be in 
better shape. 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



This communication may contain privileged and/or confidential information. It 
is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. This communication may contain nonpublic 
personal information about consumers subject to the restrictions of the 
Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose 
such information for any purpose other than to provide the services for which 
you are receiving the information.

127 Public Square, Cleveland, OH 44114
If you prefer not to receive future e-mail offers for products or services from 
Key 
send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in 
the 
SUBJECT line.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to