Export (0) Print
Expand All
Expand Minimize

Appendix J: Custom Technology Solutions Capabilities Matrix

Published: June 27, 2006
On This Page

Custom Technology Solutions Custom Technology Solutions
Capabilities Matrix for Custom Technology Solutions Capabilities Matrix for Custom Technology Solutions

Custom Technology Solutions

This appendix provides information about each of 46 capabilities for the eight custom technology solutions developed in Volume 2: Chapter 4, "Developing a Custom Solution" and described further in chapters 5–8 of Volume 2. The custom solutions described in these chapters are designed for implementing interoperability between UNIX or Linux clients and Microsoft® Windows® Active Directory® directory service to achieve End States 1 or 2:

  • End State 1. The purpose of an End State 1 solution as defined in this guide is to enable UNIX or Linux clients to use Kerberos to authenticate to Active Directory. If your solution is an End State 1 solution, UNIX clients continue to use their existing UNIX-based authorization method.

  • End State 2. The purpose of an End State 2 solution as defined in this guide is to use both Active Directory–based Kerberos authentication and Active Directory–based LDAP authorization to support logon and access to network resources for UNIX clients.

For each end state, you can choose from among multiple alternative custom technology solutions for implementing that end state. Half of the custom solutions described in this volume use native operating system (native OS) components; the other half adds the use of open source components and free software downloads:

  • Native OS custom technology solutions. A native OS solution is one that uses only components that are distributed as part of the operating system by the operating system vendor.

  • Open source custom technology solutions. An open source solution is one that uses the native operating system as a foundation but also adds Kerberos and LDAP components and tools in the form of open source software or free downloads from third-party vendors.

Open source solutions, especially on Red Hat, provide many additional features that the native OS solutions lack but are more complex to develop. Whether you choose a native OS or open source solution depends on your assessment of the advantages and limitations of each. Both native OS and open source solutions described in this volume include solutions designed and tested for Red Hat 9 Linux and for Solaris 9 UNIX.

For more information about the eight possible custom technology solutions for End States 1 and 2 described in this volume, see:

  • "Technology Solutions for End States 1 and 2" in Volume 2: Chapter 1, "Choosing the Right Technology and Planning Your Solution."

  • "Eight Custom Solutions for Solaris or Red Hat" in Volume 2: Chapter 4, "Developing a Custom Solution."

Capabilities Matrix for Custom Technology Solutions

This section includes the following related tables

  • Capabilities Matrix (Table J.2). This table lists 46 features for the eight custom technology solutions included in chapters 4–8 of Volume 2. The matrix specifies for each feature whether it is supported by End State 1 or 2, native OS or open source, or Solaris or Red Hat solutions.

  • Capabilities Matrix Description (Table J.3). This table describes each of the 46 features listed in Table J.2.

Table J.1 provides the key to the abbreviations used in the Capabilities Matrix tables and indicates what the abbreviations mean.

Table J.1. Key to Abbreviations Used in Capabilities Matrix Tables

Column Labels

Type of UNIX or Linux

End State 1 or 2

Solution Type: A (Native OS) or B (Open Source)

Sol9 - 1A

Solaris 9

End State 1

Native OS

Sol9 - 1B

Solaris 9

End State 1

Open Source

Sol9 - 2A

Solaris 9

End State 2

Native OS

Sol9 - 2B

Solaris 9

End State 2

Open Source

RH9 - 1A

Red Hat 9

End State 1

Native OS

RH9 - 1B

Red Hat 9

End State 1

Open Source

RH9 - 2A

Red Hat 9

End State 2

Native OS

RH9 - 2B

Red Hat 9

End State 2

Open Source

Table J.2. Capabilities Matrix for End States 1 and 2

Note   See the footnote list following this table for an explanation of each superscript number.

Item #

Function

Interface

Capability

Sol 9 1A

Sol 9 1B

Sol 9 2A

Sol 9 2B

RH9 1A

RH9 1B

RH9 2A

RH9 2B

1

Basic authorization

Console GUI

All of the user's Active Directory groups defined in the standard Active Directory container are returned to the UNIX workstation and display correctly with the groups command.

N/A

N/A

Yes

Yes

N/A

N/A

Yes

Yes

2

Basic authorization

Console command line or telnet

All of the user's Active Directory groups defined in the standard Active Directory container are returned to the UNIX workstation and display correctly with the groups command.

N/A

N/A

Yes

Yes

N/A

N/A

Yes

Yes

3

Active Directory tree

Console GUI

When a user is a member of a group that exists in a nonstandard Active Directory tree, this group is returned to the UNIX workstation and displays correctly with the groups command.

N/A

N/A

No

No

N/A

N/A

No

No

4

Active Directory tree

Console command line or telnet

When a user is a member of a group that exists in a nonstandard Active Directory tree, this group is returned to the UNIX workstation and displays correctly with the groups command.

N/A

N/A

No

No

N/A

N/A

No

No

5

Data caching

N/A

When authorization data is retrieved from Active Directory (for example, when a user runs the ls -l command in a UNIX shell), cached data is used to return results.

N/A

N/A

Yes

No1

N/A

N/A

Yes

Yes

6

Basic authentication

Console command line

Basic Active Directory user logon using /bin/sh

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

7

Basic authentication

Console GUI

Basic Active Directory user logon using /bin/sh

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

8

Basic authentication

su

Basic Active Directory user logon using /bin/sh

Yes

Yes

Yes

Yes

No2

No2

No3

No3

9

Basic authentication

telnet

Basic Active Directory user logon using /bin/sh

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

10

Set account lockout

Console GUI

Logon attempts with bad password set Active Directory account lockout per Active Directory Group Policy.

No5

Yes4

No5

Yes4

Yes4

Yes4

Yes4

Yes4

11

Set account lockout

Console command line or telnet

Logon attempts with bad password set Active Directory account lockout per Active Directory Group Policy.

Yes

Yes4

Yes

Yes4

Yes4

Yes4

Yes4

Yes4

12

Active Directory tree

Console GUI

Logon succeeds when user is stored in a container not in the tree of the primary Active Directory UNIX data container.

N/A

N/A

No

No

N/A

N/A

No

No

13

Active Directory tree

Console command line or telnet

Logon succeeds when user is stored in a container not in the tree of the primary Active Directory UNIX data container.

N/A

N/A

No

No

N/A

N/A

No

No

14

Active Directory down—all servers

Console GUI

Active Directory user is able to log on when no Active Directory server is found or is responding to requests (cached credentials).

No

No

No

No

No

No

No

No

15

Active Directory down—all servers

Console command line or telnet

Active Directory user is able to log on when no Active Directory server is found or is responding to requests (cached credentials).

Note   Although UNIX-based computers in the custom solutions in this guide do not cache Active Directory credentials for UNIX users with Active Directory accounts, both commercial solutions described in Volume 2 provide caching of Active Directory credentials.

No

No

No

No

No

No

No

No

16

Active Directory down—failover from primary to secondary server

Console GUI

User is able to log on when first Active Directory server defined for the UNIX-based computer is not found or is not responding to requests but the second Active Directory server defined for the workstation is (failover).

Yes

Yes

Yes

Yes7

Yes

Yes

No8

Yes7

17

Active Directory down—failover from primary to secondary server

Console command line or telnet

User is able to log on when first Active Directory server defined for the UNIX-based computer is not found or is not responding to requests but the second Active Directory server defined for the workstation is (failover).

Yes

Yes

Yes

Yes7

Yes

Yes

No8

No8

18

Account expiration

Console GUI

User is denied access when Active Directory account is expired.

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

19

Account expiration

Console command line or telnet

User is denied access when Active Directory account is expired.

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

20

Account locked out

Console GUI

User is denied access when Active Directory account is locked.

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

21

Account locked out

Console command line or telnet

User is denied access when Active Directory account is locked.

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

22

Account expiration

Console GUI

User receives specific error message at logon when account is expired (for example, "account locked" versus generic "authentication failed" message).

No

Yes

No

Yes

No

Yes

No

Yes

23

Account expiration

Console command line or telnet

User receives specific error message at logon when account is expired (for example, "account locked" versus generic "authentication failed" message).

No

Yes

No

Yes

No

Yes

No

Yes

24

Password policy

Console GUI

New password provided by user during password change during logon is required to meet Active Directory password policy.

Yes

Yes

Yes

Yes

N/A10

Yes

N/A10

Yes

25

Password policy

Console command line or telnet

New password provided by user during password change during logon is required to meet Active Directory password policy.

Yes

Yes

Yes

Yes

N/A10

Yes

N/A10

Yes

26

Manual password change

N/A

Password change with the passwd command succeeds for Active Directory.

No11

No11

No11

No11

No12

No12

No12

No12

27

Password change on logon

Console GUI

User is prompted to change password when Active Directory password is expired or set to "require password change" and logon after password change with new password succeeds.

Yes

Yes

Yes

Yes

No13

Yes

No13

Yes14

28

Password change on logon

Console command line or telnet

User is prompted to change password when Active Directory password is expired or set to "require password change" and logon after password change with new password succeeds.

Yes

Yes

Yes

Yes

No13

Yes

No13

Yes

29

Password warning

Console GUI

User receives password warning when password will expire in x days per Active Directory Group Policy.

No

Yes

No

Yes

No

Yes

No

Yes

30

Password warning

Console command line or telnet

User receives password warning when password will expire in x days per Active Directory Group Policy.

No

Yes

No

Yes

No

Yes

No

Yes

31

Security

N/A

Support for Kerberos authentication for the LDAP connection to Active Directory.

N/A

N/A

No

Yes

N/A

N/A

No

Yes

32

Basic authorization

Console GUI

User's home directory and shell are set correctly at logon.

N/A

N/A

Yes

Yes

N/A

N/A

Yes

Yes

33

Basic authorization

Console command line or telnet

User's home directory and shell are set correctly at logon.

N/A

N/A

Yes

Yes

N/A

N/A

Yes

Yes

34

Shell support

Console command line

Logon succeeds using alternate shells (as opposed to Bourne Shell).

N/A

N/A

Yes

No6

N/A

N/A

Yes

Yes

35

Shell support

Console GUI

Logon succeeds using alternate shells (as opposed to Bourne Shell).

N/A

N/A

Yes

No15

N/A

N/A

Yes

Yes

36

Shell support

su

Logon succeeds using alternate shells (as opposed to Bourne Shell).

N/A

N/A

Yes

No15

N/A

N/A

Yes

Yes

37

Shell support

telnet

Logon succeeds using alternate shells (as opposed to Bourne Shell).

N/A

N/A

Yes

No6

N/A

N/A

Yes

Yes

38

Active Directory down—all servers

Console GUI

Local nonroot user is able to log on when no Active Directory server is found or is responding to requests.

No8

No8

Yes

No8

Yes

Yes

Yes7

No8

39

Active Directory down—all servers

Console GUI

Local root user is able to log on when no Active Directory server is found or is responding to requests.

Yes

No8

Yes

Yes

Yes

Yes

Yes7

Yes7

40

Active Directory down—all servers

Console command line or telnet

Local nonroot user is able to log on when no Active Directory server is found or is responding to requests.

No8

No8

No8

No8

No8

No8

No8

No8

41

Active Directory down—all servers

Console command line or telnet

Local root user is able to log on when no Active Directory server is found or is responding to requests.

No8

No8

No8

No8

No8

No8

No8

No8

42

Manual password change

N/A

Password change with passwd succeeds for local user.

Yes9

Yes9

Yes9

No16

Yes

Yes

Yes

Yes

43

Account locked out

Console GUI

User receives specific error message at logon when account is locked (for example, "account locked" versus generic "authentication failed" message).

No

Yes

No

Yes

No

Yes

No

Yes

44

Account locked out

Console command line or telnet

User receives specific error message at logon when account is locked (for example, "account locked" versus generic "authentication failed" message).

No

Yes

No

Yes

No

Yes

No

Yes

45

Credential verification

Console command line or telnet

User is denied access if service key table is missing or incorrect.

Yes

Yes

Yes

Yes

No

Yes

No

Yes

46

Credential verification

Console GUI

User is denied access if service key table is missing or incorrect.

Yes

Yes

Yes

Yes

No

Yes

No

Yes

47

TCP support for Kerberos authentication

N/A

Solution can be configured to support the use of the TCP network protocol for Kerberos authentication.

No

Yes

No

Yes

No

Yes

No

Yes

48

Support for RC4-HMAC encryption type

N/A

Solution can be configured to support the RC4-HMAC encryption type for Kerberos authentication as well as the DES-MD5 and DES-CRC encryption types.

No

Yes17

No

Yes17

No

Yes17

No

Yes17

1 The solution presents inconsistent problems with core dumps of the nscd service. Without the nscd service running, caching cannot be done.

2 The su command succeeds, but the credentials cache is not accessible.

3 Works for some users, but not others. Doesn't return full groups data.

4 Account locks after a number of failures that is half of Group Policy (3 failures if Group Policy is set to 6).

5 End state requires that Active Directory user be configured to not require preauthentication; without preauthentication, the account will never lock.

6 Works correctly with Korn Shell (ksh), but fails with Bourne Again Shell (bash) and C Shell (csh).

7 Logon is very slow and may time out before completing, depending on logon interface configuration. Logon may fail if the first DNS server configured in the /etc/resolv.conf file is not available.

8 Logon is unacceptably slow or fails.

9 User is prompted for new password four times.

10 Because the password cannot be changed during logon with this end state, this item is not applicable.

11 The passwd command may fail invisibly or produce a segmentation fault when used by an Active Directory user. Its use is not recommended. Use kpasswd instead.

12 Only works when password meets Active Directory password policy. If password fails Active Directory password policy, password appears to be changed but isn't.

13 User is prompted to change password, but the password can't actually be changed. The user is prompted to change password continually without success.

14 Password change message is difficult to read.

15 Works correctly with Korn Shell (ksh) and C Shell (csh) but fails with Bourne Again Shell (bash).

16 The passwd command produces a segmentation fault when configured for pam_krb5 use.

17 The pam_krb5 module included in these solutions supports RC4-HMAC. However, the native OS Kerberos client tools (for example, kinit, klist, kpasswd, and ktutil) do not. In order for your deployment to fully support RC4-HMAC, you must also distribute the open source Kerberos client tools and underlying Kerberos libraries built on MIT version 1.3.5 (or later).

Table J.3. Capabilities Matrix Descriptions

Item #

Function

Interface

Capability

Description

1

Basic authorization

Console GUI

All of the user's Active Directory groups defined in the standard Active Directory container are returned to the UNIX-based workstation and display correctly with the groups command.

Is group data for an Active Directory user returned to the UNIX-based computer for all groups of which the user is a member?

See also item numbers 3 and 4 regarding groups stored in a nonstandard container in Active Directory. This question goes only to whether multiple groups within the standard container structure are returned.

2

Basic authorization

Console command line or telnet

All of the user's Active Directory groups defined in the standard Active Directory container are returned to the UNIX-based workstation and display correctly with the groups command.

Is group data for an Active Directory user returned to the UNIX-based computer for all groups of which the user is a member.

See also item numbers 3 and 4 regarding groups stored in a nonstandard container in Active Directory. This question goes only to whether multiple groups within the standard container structure are returned.

3

Active Directory tree

Console GUI

When a user is a member of a group that exists in a nonstandard Active Directory tree, this group is returned to the UNIX-based workstation and displays correctly with the groups command.

When an Active Directory user logs on to the UNIX-based computer and some of his or her groups are stored in a separate container in Active Directory, is the data for these groups returned to the UNIX-based computer, enabling the user to access resources based on membership in these groups?

When configuring LDAP authorization on the UNIX side, it is necessary to define a container that will contain the user and group data. The container defined is the "standard" container. For example, if the "standard" container is ou=chicago,dc=example,dc=com, then a nonstandard container might be ou=tampa,dc=example,dc=com.

4

Active Directory tree

Console command line or telnet

When a user is a member of a group that exists in a nonstandard Active Directory tree, this group is returned to the UNIX-based workstation and displays correctly with the groups command.

When an Active Directory user logs on to the UNIX-based computer and some of his or her groups are stored in a separate container in Active Directory, is the data for these groups returned to the UNIX-based computer, enabling the user to access resources based on membership in these groups?

When configuring LDAP authorization on the UNIX side, it is necessary to define a container that will contain the user and group data. The container defined is the "standard" container. For example, if the "standard" container is ou=chicago,dc=example,dc=com, then a nonstandard container might be ou=tampa,dc=example,dc=com.

5

Data caching

N/A

When authorization data is retrieved from Active Directory (for example, when a user runs the ls -l command in a UNIX shell), cached data is used to return results.

Is data cached on the local UNIX-based computer used to return user and group data when needed or is user and group data retrieved separately from Active Directory upon each request?

If the user and group data must be retrieved from Active Directory each time it is requested, this can create a heavy network burden in large environments. Most of the solutions described in this guide use caching to avoid this situation.

6

Basic authentication

Console command line

Basic Active Directory user logon using /bin/sh

Can an Active Directory user log on at the console command line using a standard shell?

This is basic functionality that all viable end states must support.

7

Basic authentication

Console GUI

Basic Active Directory user logon using /bin/sh

Can an Active Directory user log on at the console GUI using a standard shell?

This is basic functionality that all viable end states must support.

8

Basic authentication

su

Basic Active Directory user logon using /bin/sh

Can an Active Directory user su to another UNIX or Active Directory account using a standard shell?

This is basic functionality that all viable end states must support.

9

Basic authentication

telnet

Basic Active Directory user logon using /bin/sh

Can an Active Directory user log on via telnet using a standard shell?

This is basic functionality that all viable end states must support.

10

Set account lockout

Console GUI

Logon attempts with bad password set Active Directory account lockout per Active Directory Group Policy.

When an Active Directory user attempts to log on to a UNIX-based computer and provides an incorrect password, does this cause the user's Active Directory account to become locked after x failed attempts?

The number of logon attempts that can be made and fail before the user's account becomes locked is set in Active Directory Group Policy. Most end states set this account lockout flag. However, some of the solutions described in this guide lock the user's account after fewer logon attempt failures than set in Active Directory Group Policy because each logon attempt is considered two failures (because of underlying authentication functionality). For instance, if the Active Directory Group Policy lockout threshold is set to 5, some end states will cause the user's account to become locked after 5 failures, and others will cause the user's account to become locked after 2.5 failures (essentially 3 failures).

11

Set account lockout

Console command line or telnet

Logon attempts with bad password set Active Directory account lockout per Active Directory Group Policy.

When an Active Directory user attempts to log on to a UNIX-based computer and provides an incorrect password, does this cause the user's Active Directory account to become locked after x failed attempts?

The number of logon attempts that can be made and fail before the user's account becomes locked is set in Active Directory Group Policy. Most end states set this account lockout flag. However, some of the solutions described in this guide lock the user's account after fewer logon attempt failures than set in Active Directory Group Policy because each logon attempt is considered two failures (because of underlying authentication functionality). For instance, if the Active Directory Group Policy lockout threshold is set to 5, some end states will cause the user's account to become locked after 5 failures and others will cause the user's account to become locked after 2.5 failures (essentially 3 failures).

12

Active Directory tree

Console GUI

Logon succeeds when user is stored in a container not in the tree of the primary Active Directory UNIX data container.

Is an Active Directory user able to log on to the UNIX-based computer when his or her user account is stored in Active Directory in a separate container from that of other users generally logging on to this UNIX-based computer?

When configuring LDAP authorization on the UNIX side, it is necessary to define a container that will contain the user or group data. The container defined is the "standard" container. If the "standard" container is ou=chicago,dc=example,dc=com, then a nonstandard container might be ou=tampa,dc=example,dc=com.

13

Active Directory tree

Console command line or telnet

Logon succeeds when user is stored in a container not in the tree of the primary Active Directory UNIX data container.

Is an Active Directory user able to log on to the UNIX-based computer when his or her user account is stored in Active Directory in a separate container from that of other users generally logging on to this UNIX-based computer?

When configuring LDAP authorization on the UNIX side it is necessary to define a container that will contain the user or group data. The container defined is the "standard" container. If the "standard" container is ou=chicago,dc=example,dc=com, then a nonstandard container might be ou=tampa,dc=example,dc=com.

14

Active Directory down—all servers

Console GUI

Active Directory user is able to log on when no Active Directory server is found or is responding to requests (cached credentials).

Is an Active Directory user able to log on to the UNIX-based computer when the UNIX-based computer is unable to connect to any Active Directory server to perform authentication?

With the custom solutions described in this guide, if the UNIX-based computer is unable to connect to any Active Directory server to perform authentication, the user will be denied access. However, the commercial products described in this guide can use cached credentials to provide access when all servers are unavailable—much like the standard Windows logon with cached credentials.

15

Active Directory down—all servers

Console command line or telnet

Active Directory user is able to log on when no Active Directory server is found or is responding to requests (cached credentials).

Is an Active Directory user able to log on to the UNIX-based computer when the UNIX-based computer is unable to connect to any Active Directory server to perform authentication?

With the custom solutions described in this guide, if the UNIX-based computer is unable to connect to any Active Directory server to perform authentication, the user will be denied access. However, the commercial products described in this guide can use cached credentials to provide access when all servers are unavailable—much like the standard Windows logon with cached credentials.

16

Active Directory down—failover from primary to secondary server

Console GUI

User is able to log on when first Active Directory server defined for the UNIX-based computer is not found or is not responding to requests but the second Active Directory server defined for the workstation is (failover).

Is an Active Directory user able to log on to the UNIX-based computer when one or more Active Directory servers configured for this UNIX-based computer is not responding to requests?

Unlike a strictly Windows environment, a UNIX environment is often configured to point to specific Active Directory servers for authentication in a specific order. If the first Active Directory server queried for authentication does not respond, logon attempts for Active Directory users with some end states may be very slow. Problems with speed can be compounded if the nonresponsive Active Directory server is also configured as the first DNS server for the UNIX-based computer. Problems with nonresponsive DNS servers are more a function of how the UNIX OS handles DNS requests than anything to do with interoperability solution.

17

Active Directory down—failover from primary to secondary server

Console command line or telnet

User is able to log on when first Active Directory server defined for the UNIX-based computer is not found or is not responding to requests but the second Active Directory server defined for the workstation is (failover).

Is an Active Directory user able to log on to the UNIX-based computer when one or more Active Directory servers configured for this UNIX-based computer is not responding to requests?

Unlike a strictly Windows environment, a UNIX environment is often configured to point to specific Active Directory servers for authentication in a specific order. If the first Active Directory server queried for authentication does not respond, logon attempts for Active Directory users with some end states may be very slow. Problems with speed can be compounded if the nonresponsive Active Directory server is also configured as the first DNS server for the UNIX-based computer. Problems with nonresponsive DNS servers are more a function of how the UNIX OS handles DNS requests than anything to do with interoperability solution.

18

Account expiration

Console GUI

User is denied access when Active Directory account is expired.

When the user attempts to log on to the UNIX-based computer when his or her account is expired in Active Directory, is access denied?

19

Account expiration

Console command line or telnet

User is denied access when Active Directory account is expired.

When the user attempts to log on to the UNIX-based computer when his or her account is expired in Active Directory, is access denied?

20

Account locked out

Console GUI

User is denied access when Active Directory account is locked.

When the user attempts to log on to the UNIX-based computer when his or her account is locked in Active Directory, is access denied?

21

Account locked out

Console command line or telnet

User is denied access when Active Directory account is locked.

When the user attempts to log on to the UNIX-based computer when his or her account is locked in Active Directory, is access denied?

22

Account expiration

Console GUI

User receives specific error message at logon when account is expired (for example, "account locked" versus generic "authentication failed" message).

If a user attempts to log on to a UNIX-based computer when his or her account is expired in Active Directory and is denied access, does the error message provide a specific reason for the failure?

With many of the solutions described in this guide, when logon is denied for whatever reason (for example, account locked, account expired, or bad password), the error message to the user is generic and does not indicate why the logon attempt failed.

23

Account expiration

Console command line or telnet

User receives specific error message at logon when account is expired (for example, "account locked" versus generic "authentication failed" message).

If a user attempts to log on to a UNIX-based computer when his or her account is expired in Active Directory and is denied access, does the error message provide a specific reason for the failure?

With many of the solutions described in this guide, when logon is denied for whatever reason (for example, account locked, account expired, or bad password), the error message to the user is generic and does not indicate why the logon attempt failed.

24

Password policy

Console GUI

New password provided by user during password change during logon is required to meet Active Directory password policy.

When an Active Directory user is prompted to change his or her password during logon to the UNIX-based computer, is the new password provided by the user checked against the password policy configured in Active Directory and rejected if it does not meet the policy?

This is only a valid question for those solutions described in this guide that can be configured to prompt the user to change his or her password during logon if it is expired.

25

Password policy

Console command line or telnet

New password provided by user during password change during logon is required to meet Active Directory password policy.

When an Active Directory user is prompted to change his or her password during logon on the UNIX-based computer, is the new password provided by the user checked against the password policy configured in Active Directory and rejected if it does not meet the policy?

This is only a valid question for those solutions described in this guide that can be configured to prompt the user to change his or her password during logon if it is expired.

26

Manual password change

N/A

Password change with the passwd command succeeds for Active Directory.

If the UNIX-based computer is configured to make password changes through pam_krb5 or pam_ldap when the passwd command is executed, does the password change succeed and is it reasonably easy for the user to understand the process?

With some end states, configuration of the passwd command to use pam_krb5 or pam_ldap can cause the password change process through the passwd command to malfunction or present very confusing messages to the user during the password change process—for example, multiple prompts to the user for the old password with no indication of why the user is being prompted for the old password more than once or more than two prompts for the new password.

27

Password change on logon

Console GUI

User is prompted to change password when Active Directory password is expired or set to "require password change" and logon after password change with new password succeeds.

If the user's password is expired, is he or she prompted to change the password at logon time and then allowed to log on with the new password?

With some of the solutions described in this guide, when the user's password expires, he or she is no longer able to log on and must contact an administrator to have the password reset.

28

Password change on logon

Console command line or telnet

User is prompted to change password when Active Directory password is expired or set to "require password change" and logon after password change with new password succeeds.

If the user's password is expired, is he or she prompted to change the password at logon time and then allowed to log on with the new password?

With some of the solutions described in this guide, when the user's password expires, he or she is no longer able to log on and must contact an administrator to have the password reset.

29

Password warning

Console GUI

User receives password warning when password will expire in x days per Active Directory Group Policy.

Does the user receive a warning during logon that his or her password will expire in x days?

Many of the solutions described in this guide do not support this functionality.

30

Password warning

Console command line or telnet

User receives password warning when password will expire in x days per Active Directory Group Policy.

Does the user receive a warning during logon that his or her password will expire in x days?

Many of the solutions described in this guide do not support this functionality.

31

Security

N/A

Support for Kerberos authentication for the LDAP connection to Active Directory.

Can the authentication for the LDAP proxy account to the Active Directory directory service to retrieve LDAP authorization data for the UNIX user be configured to use Kerberos for authentication instead of using TLS or a nonsecure channel?

Most of the solutions described in this guide support either TLS authentication for the LDAP proxy user or have no support for an encrypted channel. Solutions that use TLS can create a heavier network load than solutions that use Kerberos authentication for the LDAP channel. Solutions that do not support either TLS or Kerberos and should not be used in a production environment.

32

Basic
authorization

Console GUI

User's home directory and shell are set correctly at logon.

When an Active Directory user logs on to the UNIX-based computer, is the Active Directory user's home directory and shell data set correctly?

This is basic authorization functionality and must be supported by all the solutions described in this guide that use Active Directory for authorization.

33

Basic
authorization

Console command line or telnet

User's home directory and shell are set correctly at logon.

When an Active Directory user logs on to the UNIX-based computer, is the Active Directory user's home directory and shell data set correctly?

This is basic authorization functionality and must be supported by all the solutions described in this guide that use Active Directory for authorization.

34

Shell support

Console command line

Logon succeeds using alternate shells (as opposed to Bourne Shell).

When an Active Directory user attempts to log on to a UNIX-based computer at the console command line with a UNIX shell other than the Bourne Shell (sh), does logon succeed? Is the shell set correctly on logon?

Some of the solutions described in this guide do not provide satisfactory support for all shells in all logon interface types.

35

Shell support

Console GUI

Logon succeeds using alternate shells (as opposed to Bourne Shell).

When an Active Directory user attempts to log on to a UNIX-based computer at the console command line with a UNIX shell other than the Bourne Shell (sh), does logon succeed? Is the shell set correctly on logon?

Some of the solutions described in this guide do not provide satisfactory support for all shells in all logon interface types.

36

Shell support

su

Logon succeeds using alternate shells (as opposed to Bourne Shell).

When an Active Directory user attempts to log on to a UNIX-based computer at the console command line with a UNIX shell other than the Bourne Shell (sh), does logon succeed? Is the shell set correctly on logon?

Some of the solutions described in this guide do not provide satisfactory support for all shells in all logon interface types.

37

Shell support

telnet

Logon succeeds using alternate shells (as opposed to Bourne Shell).

When an Active Directory user attempts to log on to a UNIX-based computer at the console command line with a UNIX shell other than the Bourne Shell (sh), does logon succeed? Is the shell set correctly on logon?

Some of the solutions described in this guide do not provide satisfactory support for all shells in all logon interface types.

38

Active Directory down—all servers

Console GUI

Local nonroot user is able to log on when no Active Directory server is found or is responding to requests.

Is a local nonroot user able to log on to the UNIX-based computer when the UNIX-based computer is unable to connect to any Active Directory server to perform authentication?

With some of the solutions described in this guide, local nonroot logon attempts may fail when no Active Directory server is available. In some cases the logon attempt is very slow and may or may not time out before the logon timeout window set for the computer is reached. Some logon interfaces may work better than others (for example, GUI versus console command line versus telnet). Logon success may be improved in this situation if the first DNS server configured for the UNIX-based computer (in the /etc/resolv.conf file) is responding to requests.

39

Active Directory down—all servers

Console GUI

Local root user is able to log on when no Active Directory server is found or is responding to requests.

Is a local nonroot user able to log on to the UNIX-based computer when the UNIX-based computer is unable to connect to any Active Directory server to perform authentication?

With some of the solutions described in this guide, local logon attempts as root may fail when no Active Directory server is available. In some cases the logon attempt is very slow and may or may not time out before the logon timeout window set for the computer is reached. Some logon interfaces may work better than others (for example, GUI versus console command line versus telnet). Logon success may be improved in this situation if the first DNS server configured for the UNIX-based computer (in the /etc/resolv.conf file) is responding to requests. In most cases, logon attempts with root are more likely to succeed than logon attempts as a local nonroot user, but logon attempts are often quite slow.

40

Active Directory down—all servers

Console command line or telnet

Local nonroot user is able to log on when no Active Directory server is found or is responding to requests.

Is a local nonroot user able to log on to the UNIX-based computer when the UNIX-based computer is unable to connect to any Active Directory server to perform authentication?

With some of the solutions described in this guide, local nonroot logon attempts may fail when no Active Directory server is available. In some cases the logon attempt is very slow and may or may not time out before the logon timeout window set for the computer is reached. Some logon interfaces may work better than others (for example, GUI versus console command line versus telnet). Logon success may be improved in this situation if the first DNS server configured for the UNIX-based computer (in the /etc/resolv.conf file) is responding to requests.

41

Active Directory down—all servers

Console command line or telnet

Local root user is able to log on when no Active Directory server is found or is responding to requests.

Is a local nonroot user able to log on to the UNIX-based computer when the UNIX-based computer is unable to connect to any Active Directory server to perform authentication?

With some of the solutions described in this guide, local logon attempts as root may fail when no Active Directory server is available. In some cases the logon attempt is very slow and may or may not time out before the logon timeout window set for the computer is reached. Some logon interfaces may work better than others (for example, GUI versus console command line versus telnet). Logon success may be improved in this situation if the first DNS server configured for the UNIX-based computer (in the /etc/resolv.conf file) is responding to requests. In most cases, logon attempts with root are more likely to succeed than logon attempts as a local nonroot user, but logon attempts are often quite slow.

42

Manual password change

N/A

Password change with passwd succeeds for local user.

If the UNIX-based computer is configured to make password changes through pam_krb5 or pam_ldap when the passwd command is executed, does the password change succeed and is it reasonably easy for the user to understand the process?

With some of the solutions described in this guide, configuration of the passwd command to use pam_krb5 or pam_ldap can cause the password change process through the passwd command to malfunction or present very confusing messages to the user during the password change process. For example, the user may receive multiple prompts for the old password with no indication of why the user is being prompted for the old password more than once or may receive more than two prompts for the new password.

43

Account locked out

Console GUI

User receives specific error message at logon when account is locked (for example, "account locked" versus generic "authentication failed" message).

If a user attempts to log on to a UNIX-based computer when his or her account is locked in Active Directory and is denied access, does the error message provide a specific reason for the failure?

With many of the solutions described in this guide, when logon is denied for whatever reason (for example, account locked, account expired, or bad password), the error message to the user is generic and does not indicate why the logon attempt failed.

44

Account locked out

Console command line or telnet

User receives specific error message at logon when account is locked (for example, "account locked" versus generic "authentication failed" message).

If a user attempts to log on to a UNIX-based computer when his or her account is locked in Active Directory and is denied access, does the error message provide a specific reason for the failure?

With many of the solutions described in this guide, when logon is denied for whatever reason (for example, account locked, account expired, or bad password), the error message to the user is generic and does not indicate why the logon attempt failed.

45

Credential verification

Console command line or telnet

User is denied access if service key table is missing or incorrect.

Is an Active Directory user able to log on to a UNIX-based computer configured for pam_krb5 authentication (End States 1 and 2) when the Kerberos key table for this UNIX-based computer is missing or incorrect?

For best security practice, the UNIX-based computer should deny logon to any Active Directory user when pam_krb5 is the logon method (End States 1 and 2) if the Kerberos service key table on the UNIX-based computer is missing or does not contain the correct key for the UNIX-based computer.

Failure to validate Kerberos credentials—meaning the absence of a key table does not cause logon to fail—is a significant security weakness. Security implications include:

  • The Kerberos client on the UNIX host cannot verify that replies to Kerberos requests are being received from the correct (or a valid) KDC.

  • Any Kerberos credentials that might be received by the UNIX-based computer or are found in the credentials cache on the UNIX-based computer cannot be validated as valid credentials.

46

Credential verification

Console GUI

User is denied access if service key table is missing or incorrect.

Is an Active Directory user able to log on to a UNIX-based computer configured for pam_krb5 authentication (End States 1 and 2) when the Kerberos key table for this UNIX-based computer is missing or incorrect?

For best security practice, the UNIX-based computer should deny logon to any Active Directory user when pam_krb5 is the logon method (End States 1 and 2) if the Kerberos service key table on the UNIX-based computer is missing or does not contain the correct key for the UNIX-based computer.

Failure to validate Kerberos credentials—meaning the absence of a key table does not cause logon to fail—is a significant security weakness. Security implications include:

  • The Kerberos client on the UNIX host cannot verify that replies to Kerberos requests are being received from the correct (or a valid) KDC.

  • Any Kerberos credentials that might be received by the UNIX-based computer or are found in the credentials cache on the UNIX-based computer cannot be validated as valid credentials.

47

TCP support for Kerberos authentication

N/A

Solution can be configured to support the use of the TCP network protocol for Kerberos authentication.

Can a Kerberos authentication request be sent to the Active Directory server, and can the response be received from the Active Directory server, using the TCP network protocol instead of the default UDP network protocol?

Kerberos authentication using UDP (the historical default) can fail when a user is a member of a large number of groups if this number of groups causes the PAC data to grow to exceed the limit of the UDP packet size. In this case, TCP must be used for Kerberos authentication. Some older Kerberos implementations do not support TCP for Kerberos authentication.

The number of groups that can create a problem because of the size of the PAC varies depending on the specific groups of which the user is a member (groups defined in Active Directory do not have a set size). Numbers of groups in the range of 70 or more are known to create problems.

Download

Get the Windows Security and Directory Services for UNIX Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft