21.4 Next Steps
This has been a brief introduction to LDAP-UX Client Services. There are still a number of jobs we need to concern
with. The first is something called
are directory queries that request all of a database, for example, all users or all groups.
requests of large databases could reduce network and server performance. Commands like
(with no options),
, and so on fall into this category. There are parameters (e.g., look-through
) we can set in a machine's profile that will affect enumerated commands and system calls.
We should also consider setting up a Replica Server to provide redundancy in our network. If we set up a replica server, it has an impact on the how passwords are changed. Namely, passwords can't be modified on a Replica Server because it is supposed to be a
of the real directory server. We can use the command
to affect password changes.
We also need to consider integration with other directory server products such as Windows 2000 Active Directory Service (ADS). That poses the possibility of having all of our UNIX users and passwords stored on a Windows 2000 machine. We saw a variant of that approach when we talked about CIFS 9000 and the
authentication library in
. The biggest problem with integrating UNIX and Windows logins into one directory is the support for the POSIX attributes required by UNIX login and password features. When using multiple ADS domains, it is necessary to update the Global Catalog server with the relevant POSIX attributes. Depending on the version of ADS, the
of the POSIX attributes used will be changed. Again, if you are interested in such a solution, the documentation available on http://docs/hp.com is a great starting point. An
manual is the "
Installing and Administering
-UX Client Services with Microsoft Windows 2000 Active Directory
" (part number J4269-90017) to explain all the intricacies of ADS versions and POSIX attributes.
HP-UX Trusted Systems and LDAP
coexist using the current implementation of both software
. Realistically, HP-UX Trusted Systems is the software that will need to change because the structure used for the TCB is
proprietary and it is this structure that cannot fit into an LDAP directory as it stands. This is a
stumbling block for some sites where operating system security is a prime concern. At the time of this writing, there appears to be no solution on the horizon although HP has
the fact that a solution will have to be found. An alternative solution would be to look at HP's Shadow Password software (http://software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=ShadowPassword), which allows for a password file called
whereby the encrypted passwords are accessible only by the
. This software does not give any other benefits other than removing the encrypted passwords from the world-readable
file; it does not give any of the auditing, time, and location-based access controls or password and account management features that a full-blown Trusted System offers. Although this is a significant limitation, it still offers a compromise solution until such time as HP reworks Trusted Systems to integrate with LDAP. Here is a quote from the Shadow Passwords documentation relating to integration with LDAP: "
This product may be used with the
-UX Integration product version B.03.00 or later
The last thing to mention is the use of LDAP URLs in a browser. This is now a feature of many browsers. The format of an LDAP URL is explained in the associated RFC (http://www.ietf.org/rfc/rfc1959.txt), which has some excellent examples.
As you can see, the list of
associated with setting up a directory server grows the more we try to utilize it. If this brief introduction has whetted your appetite, I would strongly suggest that you get to the
Netscape Directory Services training class and do some detailed study of the LDAP-UX Integration products manual. The manual covers some of the additional tasks I have mentioned above. It also goes through commands to add entries into the directory; for example, to add users, we can use the