Kerberos Authentication New from S 39.5.0
Attention
- To carry out the administration tasks described below, profound IT knowledge is required.
Information
- Kerberos is a standardized authentication mechanism which has to be configured on the server as well as on the client.
Notes
- The following requirements must be fulfilled for the Kerberos authentication:
- Keytab file available
- Hostname of the Key Distribution Center (KDC) known
- ServicePrincipalName (SPN) of the service known
Server Configuration
Information
- In the
config/globals.conf
configuration file, the auth.methods
configuration variable has to be set accordingly. Options available:
-
osuser
(no authentication, not secure, previous behavior)
-
interactive
(the usual login message box, secure due to challenge response authentication, previous behavior)
-
kerberos
-
legacy
(is composed of the previous authentication methods osuser
and interactive
)
-
secure
(is composed of the authentication methods, enabling a secure login, currently interactive
and kerberos
)
-
proxy
authentication via a preceding software component (required the use of PLANTA secure)
-
any
(is composed of all implemented authentification methods)
- or a random combination of the above mentioned values that are listed, with blank characters and/or punctuation separating them, so that it results in a conjunction of all mentioned individual or combined methods.
Notes
- Non configured authentification methods are not allowed anymore.
- The configuration options constitute a central point for turning off the
osuser
login for all users at once.
Details
- for a backward-compatible behavior,
auth.methods
is set to legacy
by default.
- As long as this value is set, there will be no changes with regard to previous versions.
- In
config/globals.conf
, the krb.conf
and auth.conf
parameters, each determine a path for particular configuration files.
-
krb.conf
is a Kerberos configuration, determining realms, domains, KDCs as well as encrypting algorithms.
- If a system-wide JAAS compatible configuration file already exists, it can be used as well. Otherwise, the template can also be adjusted to the customer installation.
-
auth.conf
determines how the PLANTA server logs on using its own service account. An area named PlantaServer
is required in order for the code to be able to find the settings. Here, the principal
path as well as the keyTab
/ ticketCache
path can be adjusted according to your needs. All further settings, especially doNotPrompt
, should remain unchanged.
- Keytab files are usually created by the system administrator in order to adjust the corresponding principals and service accounts. The system administrator should know best how to create them correctly and how the corresponding principals in
config/auth.conf
are to be specified.
- The dissolution of Kerberos Principal based on the PLANTA user name/code is solved in Python in order for the customer to be able to map any
user@REALM
combination to a random PLANTA user.
- In the
ppms.krb5_login
Python module, a krb5_login_resolve_username(Principal)
method is defined, providing a customer specific option to map a Kerberos Principal to its corresponding PLANTA user name. This Python method is documented with respect to the parameters and the expected return value. The actual implementation has to be defined separately for each installation.
Client Configuration
Information
- The client configuration parameters can be specified in the command line or the
ini
file.
-
authentication=kerberos
- Activates the Kerberos ticket editing (required)
-
spn=<service>/<service_account>@<REALM>
- Here, the canonic SPN must be entered, e.g.
PLANTA/planta_server@EXAMPLE.COM
(required).
-
mutual=on
- Activates the mutual authentification (optional)
Note
- When a configuration parameter is specified in the
ini
file, no additional quotation marks (e.g. in the SPN) or additional blank spaces (e.g. at the end of a line) must be used.
Configure the Encryption Settings for User Accounts in Active Directory
Exemplary Set-Up of a Service Account for Kerberos Authentification in the Active Directory
1. Creation of a user in the AD tree
- Open Active Directory Users and Computers on the domain controller
- Create a new user with the required name (e.g. service name) via Create a new user in the current container
2. Setting of a service principal name (SPN) via the
setspn command
- Execute
setspn -A <SPN> <account>
- Name schema: <Service name>/<Identifier, z.B. host name>
- Example:
setspn -A PLANTA/srv_planta.mydomain.com planta_service
- A SPN must only be allocated once.
- Otherwise the client aborts the ticket request with the SEC_E_TARGET_UNKNOWN error message.
- The check can be done via
setspn -Q <SPN>
: Here, only an account must be returned.
3. Creation of a
keytab file via
ktpass
- Syntax:
ktpass /princ <SPN> /mapuser <Domain\User@DOMAIN> /pass <password> /out <keytab filename>
- Example with the previous values:
ktpass /princ PLANTA/srv_planta@MYDOMAIN.COM -setupn /mapuser XYZ\planta_service /pass gehe1m /out planta_service.keytab
- Note
- The domain must necessarily be specified in capital letters
- The
-setupn
parameter used here prevents the user account from being overwritten.
- This may be required for SPNs which cannot be used as user names.
- Copy the keytab file to the configuration directory of the server
- Protect the file against unauthorized reading