Document Information
Preface
Part I About Naming and Directory Services
1. Naming and Directory Services (Overview)
2. The Name Service Switch (Overview)
Part II DNS Setup and Administration
3. DNS Setup and Administration (Reference)
Part III NIS Setup and Administration
4. Network Information Service (NIS) (Overview)
5. Setting Up and Configuring NIS Service
6. Administering NIS (Tasks)
7. NIS Troubleshooting
Part IV LDAP Naming Services Setup and Administration
8. Introduction to LDAP Naming Services (Overview/Reference)
9. LDAP Basic Components and Concepts (Overview)
10. Planning Requirements for LDAP Naming Services (Tasks)
11. Setting Up Sun Java System Directory Server With LDAP Clients (Tasks)
12. Setting Up LDAP Clients (Tasks)
13. LDAP Troubleshooting (Reference)
14. LDAP General Reference (Reference)
15. Transitioning From NIS to LDAP (Overview/Tasks)
16. Transitioning From NIS+ to LDAP
NIS+ to LDAP Overview
Getting Started With the NIS+ to LDAP Transition
Masters and Replicas (NIS+ to LDAP)
The Directory Server (NIS+ to LDAP)
Mapping NIS+ Objects Other Than Table Entries
NIS+ Entry Owner, Group, Access, and TTL
client_info and timezone Tables (NIS+ to LDAP)
Adding New Object Mappings (NIS+ to LDAP)
Storing Configuration Information in LDAP
Part V Active Directory Naming Service
17. Setting Up Solaris Active Directory Clients
A. Solaris 10 Software Updates to DNS, NIS, and LDAP
Service Management Facility Changes
DNS BIND
pam_ldap Changes
Documentation Errors
Glossary
Index
|
Principal Names and Netnames (NIS+ to LDAP)
NIS+ authentication relies on principal names (a user or host name, qualified by
the domain name) and netnames (the secure RPC equivalent of principal names) to
uniquely identify an entity (principal) that can be authenticated. While RFC 2307 provides
for storing the Diffie-Hellman keys used for NIS+ authentication, there is no specified
place for the principal names or netnames. The /var/nis/NIS+LDAPmapping.template file works around this problem by deriving the domain portion of
principal and netnames from the owner name (itself a principal name) of the
cred.org_dir table. Hence, if the NIS+ domain is x.y.z., and the owner of
the cred.org_dir table is aaa.x.y.z., all principal names for NIS+ entries created from
LDAP data will be of the following form. user or system.x.y.z. Netnames are of the following form. unix.uid@x.y.z. unix.nodename@x.y.z. While this method of constructing principal and netnames probably is sufficient for most
NIS+ installations, there are also some cases in which it fails, as shown
in the following.
The owner name of the cred.org_dir table belongs to a different domain than the one shared by the principal and netnames in the cred.org_dir table. This could be the case for a cred.org_dir table in a subdomain, if the owner is a principal from the parent domain. You can fix this problem in one of the following ways.
Change the owner of the cred.org_dir table to match the domain of the entries in the table.
Change the mapping rules for the cred.org_dir database IDs to use the owner of some other NIS+ object (which could be created especially for that purpose, if no suitable object already exists). For example, if the cred.org_dir table in the domain sub.dom.ain. is owned by master.dom.ain., but principal and netnames in cred.org_dir.sub.dom.ain. should belong to sub.dom.ain, you could create a link object as follows. # nisln cred.org_dir.sub.dom.ain. \
credname.sub.dom.ain. Set the owner of the link object to an appropriate principal in the sub.dom.ain. as follows. # nischown trusted.sub.dom.ain. credname.sub.dom.ain. Edit the mapping file. Change (nis+:zo_owner[]cred.org_dir, "*.%s")), \ to (nis+:zo_owner[]credname.sub.dom.ain., "*.%s")), \ Note that the use of a link object called credname is an example. Any valid object type (except an entry object) and object name will do. The important point is to set the owner of the object to have the correct domain name.
If you do not want to give ownership even of a special purpose object to a principal from the domain used for the principal and netnames, create nisplusPrincipalName and nisplusNetname attributes as detailed below.
The cred.org_dir table contains principal and netnames belonging to more than one domain. Consult the documentation for your LDAP server, and create the nisplusPrincipalName and nisplusNetname attributes, as well as the nisplusAuthName object class. (The following is LDIF data for ldapadd. Attribute and object class OIDs are for illustration only.) dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.7.0 NAME 'nisplusPrincipalName' \
DESC 'NIS+ principal name' \
SINGLE-VALUE \
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.9.0 NAME 'nisplusNetname' \
DESC 'Secure RPC netname' \
SINGLE-VALUE \
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
dn: cn=schema
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.42.2.27.5.42.42.10.0 NAME 'nisplusAuthName' \
SUP top AUXILLIARY DESC 'NIS+ authentication identifiers' \
MAY ( nisplusPrincipalName $ nisplusNetname ) ) You now need to enable the cred.org_dir mapping to use the newly created nisplusNetname and nisplusPrincipalName attributes. The template mapping file, /var/nis/NIS+LDAPmapping.template, contains commented-out lines for this purpose. See the nisplusObjectDN and nisplusLDAPattributeFromColumn/ nisplusLDAPcolumnFromAttribute attribute values for the credlocal, creduser, and crednode database IDs. Once you have edited your mapping file to this effect, restart the NIS+ service. Do not forget to edit the /lib/svc/method/nisplus file to include the -m and -Y options, or use the svcprop command, as appropriate. See NIS+ to LDAP Tools and the Service Management Facility for more information.Do not forget to add the -m option if your mapping file is not the default, and the -Y option if the rpc.nisd daemon should provide NIS (YP) emulation. # svcadm restart network/rpc/nisplus:default # pkill rpc.nisd
|