Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)
Previous Next

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
Previous Next

 
 
  Published under the terms fo the Public Documentation License Version 1.01. Design by Interspire