This topic describes how
-
A user is identified to a system as a Kerberos user.
-
A Kerberos user identity is created and mapped to a local usercode.
-
Kerberos evaluates the user identity to determine usercode mapping.
A user who has access to a network, of which an MCP system is a part, may have identified himself or herself to the network by providing his or her Kerberos principal ID and corresponding password.
If the network provides station transfer capabilities, the user can request connection to the ClearPath MCP server. Provided that parts of the network communicate by using Kerberos authentication mechanisms, the ClearPath MCP server is contacted by an initiating node of the network, which provides authentication information to the MCP.
If the MCP is able to verify this information and the user has his or her Kerberos identity registered at that ClearPath MCP server, then the user is logged on automatically and the Kerberos identity is mapped to a local usercode. The user will then have access to his or her files and system access attributes.
Establishing a Mapping from a Kerberos Identity to a Usercode
The system administrator can establish a local alias usercode to correspond to a given Kerberos principal ID with the KERBEROS command.
Establishing a Kerberos Identity Mapping
This statement adds an entry to the USERDATAFILE mapping the specified principal ID to a usercode or action.
Syntax
─ + ─ KERBEROS─┬─────┬─ <principal ID> ── LOCALALIAS── = ─ <mapping>──┤
└─ = ─┘<principal ID>
─ " ──┬─ <principal name> ─┬─ @ ─┬─ <realm name> ──┬─ " ──────────────┤
├─ *SAMENAME ────────┤ └─ *ANYREALM ─────┘
└─ *ANYNAME ─────────┘ <mapping>
─────┬─ <usercode> ──┬────────────────────────────────────────────────┤
├─ "*ERROR" ────┤
└─ "*NEXT" ─────┘ Explanation
For an explanation of the action, see “How Kerberos Translates a Principal ID to a Usercode” later in this section.
| Note: | The existence of a mapping from a Kerberos principal ID to a usercode does not imply that the usercode has been defined in the USERDATAFILE. However, when the principal ID attempts to connect to the system, the existence of the usercode is verified. |
Modifying a Kerberos Identity Mapping
This statement modifies the mapping for an existing principal ID.
Syntax
───── KERBEROS─┬─────┬─ <principal ID> ── LOCALALIAS── = ─ <mapping>──┤
└─ = ─┘Explanation
Use this statement to modify the local alias to some other usercode for a Kerberos user whose local alias was previously established.
Removing a Kerberos Identity Mapping
This statement deletes the mapping for the specified principal ID.
Syntax
──── - ─── KERBEROS─┬─────┬─── <principal ID> ───────────────────────┤
└─ = ─┘Explanation
An entry can be removed from the USERDATAFILE with this statement. Note that in this case, the LOCALALIAS clause must not be specified.
Inquiring about Kerberos Identity Mappings
This statement shows the entry corresponding to the requested principal ID.
Syntax
───── KERBEROS─┬─────┬─── <principal ID> ────────────────────────────┤
└─ = ─┘For more information about the Kerberos security feature and implementation, refer to the Kerberos Security Configuration and Administration Guide.
How Kerberos Translates a Principal ID to a Usercode
Depending on the security needs required for a system, a security administrator can tailor access to a system depending on the <principal name> and <realm name> of the Kerberos user principal ID. The access can be as restrictive or flexible as desired.
The algorithm described in the following table is used by Kerberos to translate a principal ID to a usercode.
A principal ID takes the form “<principal name>@<realm name>” (for example, “john@MV.UNISYS.COM”). The realm name can be either the local realm (that is, the Kerberos realm to which the local host belongs), or a remote realm. Note that both principal ID components, <principal name> and <realm name>, are case-sensitive.
In the following algorithm, Step 1 is taken only if the realm name of the principal ID is the local realm. Step 2 is performed when the realm name of the principal ID is a remote realm.
-
Kerberos looks for a matching entry in the Kerberos section of the USERDATAFILE of the form:
"<principal name>" LOCALALIAS = <usercode>
If a matching entry is not found, then Step 2 is performed.
If this search is successful, the principal ID is explicitly translated to the usercode specified in the entry. Because the user realm is the same as the local realm, the entry in the USERDATAFILE is not required to include the “@<realm name>” part.
-
Kerberos looks for a matching entry in the Kerberos section of the USERDATAFILE of the form:
"<principal name>@<realm name>" LOCALALIAS = <usercode>
If a matching entry is not found, then Step 3 is performed.
If a match to both principal name and realm name is found, then the principal ID is explicitly translated to the usercode specified in the entry.
-
Kerberos looks for a matching entry in the Kerberos section of the USERDATAFILE of the form:
"*SAMENAME@<realm name>" LOCALALIAS = <action>
If a matching entry is not found, then Step 4 is performed.
If the realm name of the principal ID matches, then Kerberos does one of four things in the following order:
-
Kerberos searches for an uppercase equivalent of the principal name component in the USER section of the USERDATAFILE. If such a usercode is found, then it is supplied as an alias for the principal ID. This syntax is useful to avoid explicitly mapping every principal ID in a given realm to its identical (except for letter-casing) MCP usercode.
-
If such a usercode is not found and the action specified is *ERROR, then no alias is supplied. This syntax is useful for excluding users from a specific realm. Such an entry might look like the following:
"*SAMENAME@MV.UNISYS.COM" LOCALALIAS = "*ERROR"
-
If such a usercode is not found and the action specified is “*NEXT”, then Kerberos looks for an entry of the form in Step 5.
-
If such a usercode is not found and the action specified is a usercode, then Kerberos translates the principal ID to that usercode. This syntax is useful for admitting users of a specified realm on a limited basis. Such an entry might look like this:
"*SAMENAME@MV.UNISYS.COM" LOCALALIAS = GUEST
-
-
Kerberos looks for a matching entry in the Kerberos section of the USERDATAFILE of the form:
"*SAMENAME@*ANYREALM" LOCALALIAS=<action>
If a matching entry is not found, then Step 5 is performed.
If a matching entry is found, the Kerberos performs the search in Step 3. This entry does not screen on the basis of realm name.
-
Kerberos looks for a matching entry in the Kerberos section of the USERDATAFILE of the form:
"*ANYNAME@<realm name>" LOCALALIAS=<action>
If a matching entry is not found, then Step 6 is performed.
This entry does not screen on the basis of principal name. Additionally, the action for this form can be either “ERROR” or a usercode only.
In the following example, a user will be denied system access when the realm name of the user principal ID matches the statement found in the USERDATAFILE. This statement enables the security administrator to deny access to users from a particular realm.
"*ANYNAME@TESTREALM.COM" LOCALALIAS="*ERROR"
In the following example, a user is allowed system access with the alias usercode GUEST when the realm name of the user principal ID matches the statement found in the USERDATAFILE. This statement enables the security administrator to allow access for all users from a particular realm without the need to specify each and every usercode.
"*ANYNAME@MV.UNISYS.COM" LOCALALIAS=GUEST
-
Kerberos looks for a matching entry in the Kerberos section of the USERDATAFILE of the form:
"*ANYNAME@*ANYREALM" LOCALALIAS=<usercode>
This syntax is useful for admitting anyone to the system on a restricted basis. The following form admits all users with the usercode of GUEST.
"*ANYNAME@*ANYREALM" LOCALALIAS=GUEST
