Safeguard Authentication Services supports IPv6 and is designed to run equally in IPv4-only, dual-stack (IPv4 and IPv6), and IPv6-only environments. The following describes the IPv6 features and considerations when running Safeguard Authentication Services in an IPv6-enabled environment.
NOTE: Safeguard Authentication Services uses IPv6 when the operating system's DNS resolver correctly supports mapping of IPv4 addresses to IPv6 addresses. If a problem with address mapping is detected, Safeguard Authentication Services operates in IPv4-only mode, even if an IPv6 address is assigned and other applications use IPv6.
Safeguard Authentication Services uses IPv6 automatically when DNS contains IPv6 address records (AAAA records). These are most commonly published for servers running Windows 2008 or later on an IPv6-enabled network. Similarly, hosts may use IPv4 whenever IPv4 address records (A records) appear in DNS.
To ensure reliability, when connecting to a TCP service that is available over both IPv4 and IPv6, Safeguard Authentication Services uses an adaptive algorithm used by popular web browsers and published in RFC 6555. If an initial connection attempt does not complete in a short amount of time, it makes a parallel connection attempt using a subsequent address, if available. This happens in a fraction of a second and is usually invisible to the user, even if one protocol is perennially unavailable.
For UDP connections, the service sends packets in parallel using both protocols (when available). This provides the best performance and reliability, with a negligible effect on network traffic.
IPv6 connectivity in Safeguard Authentication Services depends on the operating system. To determine IPv6 availability on a host-by-host basis, run vastool info ipv6 on each client.
NOTE: You may need to update or patch your operating system for Safeguard Authentication Services to use IPv6.
The system resolver's address selection policies directly influence the addresses chosen by Safeguard Authentication Services when more than one address is available. Depending on the operating system, you may be able to configure the polices. For example, configure /etc/gai.conf on GNU libc-based operating systems. The standard address selection policies (RFC 3484) and fallback connection algorithm should obviate the need to alter the default address selection policy.
NOTE: Active Directory servers must be running Windows 2008 or later for IPv6 communication.
Kerberos armoring, also referred to as FAST (Flexible Authentication Secure Tunneling), is an enhancement to the Kerberos protocol designed to strengthen the security of the authentication process and the retrieval of service tickets. It operates by establishing a secure tunnel between the client and the Key Distribution Center (KDC) using an armored key. This armored key is an extra encryption key generated by the KDC during the initial authentication of the host machine account, ensuring the security of Kerberos message exchanges.
Enabling armoring
Kerberos armoring has to be enabled for the KDC and the clients separately using Group Policy Management Console (GPMC).
For the KDC, the option can be found under:
Computer Configuration > Policies > Administrative Templates > System > KDC
The support can be enabled or even enforced, if the option is set to "Fail unarmored authentication requests". In enforced mode, unarmored kerberos authentication requests will be rejected.
For the kerberos clients, armoring can be enabled under:
Computer Configuration > Policies > Administrative Templates > System > Kerberos
If set, and Safeguard Group Policy (vasgp package) is installed on the UNIX client, the next group policy apply will create a configuration entry in vas.conf called "use_fast" under the "gpo" section and subsequent kerberos requests will be armored.
Armoring can also be enabled or disabled on the Unix clients without group policy: you can set "use_fast" under the "libdefaults" section in vas.conf. This overrides the value set under the "gpo" section (the group policy value).
[libdefaults] |
use_fast = true |
vas-armord
The armor key is derived from the kerberos login of the host machine. Getting that requires access to the default keytab (host.keytab) which contains the login credentials of the host machine. A non root user on the machine might not be able to access these credentials, otherwise they could act in the name of the computer. However they still need to be able to login using their own identity (with armored requests). This problem is solved by vas-armord.
If armoring is enabled either through group policy or manually, vasd will spawn this extra process automatically, which serve the encryption algorithm used for strengthening the security of the kerberos authentication.
$ sudo vastool info processes |
Parent: 14198 |
Dispatcher: 14200 |
Database: 14204 |
Permanent IPC: 14347 |
Authentication: 14349 |
FAST Armor IPC: 14220 |
Limitations
Armoring the request requires the armor key, which is obtained through the kerberos authentication of the host computer object.
In practice this means that:
This means that a new computer cannot be joined using an administrator account if kerberos armoring is enforced on the KDC, because the machine's keytab is not yet available to armor the authentication of the administrator. With enforced kerberos armoring, you can join new machines using a djoin file (see Offline Domain Join (ODJ) credentials). This way the computer object will be created by the "djoin.exe" command on the domain controller, and the initial credentials of it will be transferred with the djoin file to the unix client.
Example:
# create the computer object and the djoin file on the active directory: |
ssh Administrator@ad.company.com djoin.exe /reuse /provision /domain company.com /machine myunixhost /primarydns myunixhost.company.com /savefile "C:/myunixhost.djoin" |
# transfer somehow the resulting djoin file to the host machine |
scp -r "Administrator@ad.company.com:'C:/myunixhost.djoin'" . |
# call vastool to do the joinvastool join -j "myunixhost.djoin" |
For similar reasons, administrator login checks will not work for the "preflight" utility before joining the machine. In this case you can safely ignore the authentication failures.
Authentication Services does not currently support armoring the request using anonymous pkinit.
The "kinit" test tool will not armor the request by default (but has options to do so). Use the command "vastool kinit" nstead.
Example:
# For doing an armored request using the "kinit" test tool, first obtain the login |
# ticket of the host into a credential cache (/tmp/fast), and specify this cache to the |
# "--fast-armor-cache" option to initiate the armored kerberos login: |
/opt/quest/bin/kinit -c /tmp/fast -t /etc/opt/quest/vas/host.keytab "myunixhost$" |
/opt/quest/bin/kinit --fast-armor-cache=/tmp/fast exampleUser |
# vastool will do the same automatically: |
vastool kinit exampleUser |
Safeguard Authentication Services provides many features designed to help you consolidate and organize your identity infrastructure by bringing UNIX identity information into Active Directory. This section introduces you to some of the identity management tools available to you.
NOTE: You can access your UNIX hosts from the Control Center to perform the command line tasks described in this section.
Before you deploy Safeguard Authentication Services in your enterprise, One Identity recommends that you have a strategy for resolving the user identities on each UNIX host against Active Directory. Safeguard Authentication Services supports the following methods:
-
Enterprise Identity. UNIX User and Group identities have their Posix identity information centrally managed within Active Directory. All entities have the same credential information across the enterprise.
-
Mapped User. User identity information is local to each UNIX Host, however Active Directory users are mapped to a local UNIX account. This enables the user to authenticate using an Active Directory password, while maintaining his existing local identity.
-
Posix Identity Auto-generation. User identity information is not stored centrally within Active Directory, however Active Directory users have Posix identity attributes automatically generated for them when interacting with UNIX Hosts. Users authenticate with an Active Directory password.
-
Personalities. Personalities allow an Active Directory user to have multiple identity objects stored in Active Directory, allowing for multiple roles, multiple NIS domain consolidation, and so forth.
The following table describes each strategy, potential use cases, specific considerations, and the location in the Safeguard Authentication Services Administration Guide for more information.
Table 11: User deployment scenarios
|
Enterprise Identity
For more details, see Managing UNIX users with MMC. |
|
Posix attributes for both Users and Groups are stored in Active Directory. Active Directory users authenticate using Active Directory credentials. |
Enterprise identity is already defined within the corporation. User/Group identity/Authentication extended to UNIX. |
UID/GID uniqueness, sufficient AD schema (for example, RFC2307), account provisioning privileges. |
|
Mapped User
For more details, see Mapping local users to Active Directory users. |
|
Posix attributes for users are stored locally (for example, /etc/passwd file), and Active Directory users are mapped to a local account. The UNIX credential contains local identity information and Active Directory authentication. |
UNIX machines have predefined user identity (via /etc/passwd) but desire authentication auditing controls. Mapped User is typically a transitory state where the end state is Enterprise Identity. |
Map-file management, new account provisioning, account migration details (file ownership alignment, and so on) |
|
Autogen
For more details, see Automatically generating Posix user identities. |
|
Active Directory Users and Groups do not have posix attributes assigned to them. Safeguard Authentication Services generates posix attributes for users and groups for identity purposes, and Active Directory password is used for authentication. |
Enterprise Identity accounts are not provisioned in Active Directory, or UNIX Admin does not have permissions to provision Enterprise Identity accounts, and the UNIX hosts have joined the Active Directory domain. Admins want AD users to log in to UNIX machines with AD credentials. |
Potential for disparate UID/GID for same user, account migration details (file ownership alignment, and so on) |
|
Personalities
For more details, see UNIX Personality Management. |
|
Active Directory Users have many personalities, typically defined by membership in many NIS domains. Each personality represents a separate NIS identity. A UNIX host defines which personality to use when joined to Active Directory. Identity is supplied by personality data stored in the directory, and authentication utilizes Active Directory passwords. |
Many NIS domains have been collapsed into a single Active Directory domain. UNIX information across domains are not unique. Also used as a transitory migration state to Enterprise Identity. |
Personality management, personality OU architecture, new account provisioning, account migration details, domain separation. |
For more information see the vastool, vasd, and vas.conf man pages.
