Authentication Service and Privilege Elevation Service Limitations

The following sections describe common limitations associated with the Authentication Service and Privilege Elevation Service.

The Authentication Service and Privilege Elevation Service release notes formally listed this information under the title 'Known Issues'.

For the most up to date list of known issues, please login to the Customer Support Portal at https://support.delinea.com/s/ and refer to Knowledge Base articles for any known issues with the release.

Server Suite DirectControl Agent for *NIX

  • Known Issues with the upgrade:

    • When upgrading release 2022.1 and older to release 2023 and newer releases on aarch64 and PPC platforms you may see an error/warning like "adinfo: double free or corruption", you can ignore the error/warning, the upgrade will continue successfully and everything will work fine after that. (Ref: 560452)

  • Known Issues with Multi-Factor Authentication (MFA):

    • If MFA is enabled but the parameter "adclient.legacyzone.mfa.required.groups" is set to a non-existent group, all AD users will be required for MFA. The workaround is to remove any non-existent groups from the parameter. (Ref: CS-39591b)

  • Known Issues with AIX:

    • On AIX, upgrading DirectControl agent from 5.0.2 or older versions in disconnected mode may cause unexpected behavior. The centrifydc service may be down after the upgrade. It's recommended not to upgrade DirectControl agent in disconnected mode. (Ref: CS-30494a)

    • Some versions of AIX can't handle a username longer than eight characters. As a preventive measure, we have added a new test case in the adcheck command to check if the parameter LOGIN_NAME_MAX is set to 9. If yes, adcheck will show a warning so that users can be aware of it. (Ref: CS-30789a)

  • Known issues with Fedora 19 and above: (Ref: CS-31549a, CS-31730a)

    • The adcheck command will fail if the machine does not have Perl installed.

    • Group Policy will not be fully functional unless Text/ParseWords.pm is installed.

  • Known issues with RedHat:

    • When logging into a RedHat system using an Active Directory user that has the same name as a local user, the system will not warn the user of the conflict, which will result in unpredictable login behavior. The workaround is to remove the conflict or login with a different AD user. (Ref: CS-28940a, CS-28941a)

    • Known issues with rsh / rlogin (Ref: IN-90001)

    • When using rsh or rlogin to access a computer that has DirectControl agent installed, and where the user is required to change their password, users are prompted to change their password twice. Users may use the same password each time they are prompted, and the password is successfully changed.

  • Known issues with compatibility:

    • DirectControl SELinux module is not compatible with RHEL 6.0 and the installation of the module will fail on RHEL 6.0. If SELinux is required, please upgrade to RHEL 6.1 or above, or upgrade the SELinux policy on the system. (Ref: 503757)

    • Default zone is not used in DirectControl 5.x (Ref: IN-90001)

      • In DirectControl 4.x, and earlier, there was a concept of the default zone. When Access Manager was installed, a special zone could be created as the default zone. If no zone was specified when joining a domain with adjoin, the default zone would be used.

      • This concept has been removed from DirectControl 5.0.0 and later as it is no longer relevant with hierarchical zones. In zoned mode, a zone must now always be specified.

      • A zone called "default" may be created, and default zones created in earlier versions of Access Manager may be used, but the name must be explicitly used.

Smart Card

  • There is a Red Hat Linux desktop selection issue found in RHEL 7 with smart card login. When login with smart card, if both GNOME and KDE desktops are installed, user can only log into GNOME desktop even though "KDE Plasma Workspace" option is selected. (Ref: CS-35125a)

  • When a SmartCard user attempts to login with a password that has expired, the authentication error message may not mention that authentication has failed due to an expired password. (Ref: CS-28305a)

  • Any SmartCard user will get a PIN prompt even if he's not zoned, even though the login attempt will ultimately fail. (Ref: CS-33175c)

  • If a SmartCard user's Active Directory password expires while in disconnected mode, the user may still be able to log into their machine using their expired password. This is not a usualcase, as secure SmartCard AD environments usually do not allow both PIN and Password logins while using a Smart Card. (Ref: CS-28926a)

  • To login successfully in disconnected mode (Ref: CS-29111a):

    • For a password user:

      * A password user must log in successfully once in connected mode prior to logging in using disconnected mode. (This is consistent with other DirectControl agent for *NIX behavior)

      • For a SmartCard user:
        • The above is not true of SmartCard login. Given a properly configured RedHat system with valid certificate trust chain and CRL set up, a SmartCard user may successfully login using disconnected mode even without prior successful logins in connected mode.
          • If certificate trust chain is not configured properly on the RedHat system, the SmartCard user's login attempt will fail.
          • If the SmartCard user's login certificate has been revoked, and the RedHat system has a valid CRL that includes this certificate, then the system will reject the user.

  • When CRL check is set via Group Policy and attempting to authenticate via Smartcard, authentication may fail. The workaround is to wait until the Group Policy Update interval has occurred andtry again or to force an immediate Group Policy update by running the CLI command adgpupdate. (Ref: CS-30090c)

  • A name-mapping user can unlock screen with password even though the previous login was with PIN. (Ref: CS-31364b)

  • Need to input PIN twice to login using CAC card with PIN on RedHat. It will fail on the first input but succeed on the second one. (Ref: CS-30551c)

  • Running "sctool -D" with normal user will provide wrong CRL check result. The work-around is to run it as root. (Ref: CS-31357b)

  • Screen saver shows password not PIN prompt (Ref: CS-31559a)

Most smart card users can log on with a smart card and PIN only and cannot authenticate with a username and password. However, it is possible to configure users for both smart card/PIN and username/password authentication. Generally, this set up works seamlessly: the user either enters a username and password at the log on prompt, or inserts a smart card and enters a PIN at the prompt.

However, for multi-user cards, it can be problematic when the screen locks and the card is in the reader. When a user attempts to unlock the screen, the system prompts for a password, not for a PIN, although the PIN is required because the card is in the reader. If the user is not aware that the card is still in the reader and enters his password multiple times, the card will lock once the limit for incorrect entries is reached.

On RHEL 7, an authenticated Active Directory user via smart card cannot login again if the smart card is removed. This is due to a bug in RHEL 7, https://bugzilla.redhat.com/show_bug.cgi?id=1238342. This problem does not happen on RHEL6. (Ref: CSSSUP-6914c)