Although I have only used RACF TERMINAL profiles for userid/password
logon control, I believe they would equally apply to any logon,
including one using client certificates.
If you can restrict your admin users to specific set of LU names with a
unique naming convention, then you don't need an exit to restrict those
users to logging on with that set of LU's, just use the RACF TERMINAL
class and generic profiles in that class. Let most users logon via
arbitrary LU's via access to TERMUACC, and be sure you have generic
profiles covering all their allowed LU's with READ UACC allowed.
Connect the admin users to RACF group without TERMUACC, insure that the
TERMINAL profile covering their special LU names does not have READ UACC
and that READ access is only explicitly granted to RACF group(s)
associated with admins or to specific admin userids. Then admin userids
will only be able to logon to a 3270 session when the request is
associated with their specific set of LU's. The same profile class
also restricts logons in the TCP/IP environment (e.g., FTP servers etc.)
using a hex representation of the IP address as the terminal name. Be
sure you have enough generic profiles to cover everything of interest
and allow existing default logon behavior before activating the TERMINAL
class, or you may suddenly have all sorts of unexpected logon failures.
It is useful, if you want to restrict certain user logons to specific
subset of physical sites, to have the IP Address assignments of those
sites restricted to known IP ranges or subnets. Then TCP/IP logons
can use generic TERMINAL profiles covering those IP ranges to control
TCP/IP logons from userIDs that should either be restricted to or
disallowed from those locations, and TN3270 can then be configured to
map IP addresses in those ranges to uniquely-named LU's for that
location so that similar controls can be imposed on 3270 logons in the
VTAM environment that originate from those locations.
As with anything affecting logon ability, proceed with caution. If RACF
changes prevent future logons from RACF SPECIAL users, then you may be SOL.
Joel C. Ewing
On 12/05/2012 08:01 AM, Tom Ambros wrote:
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 <[email protected]>
To: [email protected]
Date: 12/04/2012 17:27
Subject: Re: Correlating workstation userid to TN3270 logon using
client certificates
Sent by: IBM Mainframe Discussion List <[email protected]>
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:[email protected]] On
Behalf Of Tom Ambros
Sent: Tuesday, December 04, 2012 11:25 AM
To: [email protected]
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.
...
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
