|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) B14082-02 |
|
 Previous |
 Next |
|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) B14082-02 |
|
|
Previous |
Next |
This chapter explains how to manage an Oracle directory server by using Oracle Directory Manager and command-line tools.
This chapter contains these topics:
Changing the Password to the Oracle Internet Directory Database Server
Locating Directory Servers in a Distributed Environment
|
See Also: Chapter 3, "Post-Installation Tasks and Information" for instructions on starting and stopping directory server instances |
When you start an Oracle directory server by using the object class, that start message refers to a configuration set entry containing server parameters. You can add, modify, and delete configuration set entries by using either Oracle Directory Manager or the appropriate command-line tool.
This section contains these topics:
Preliminary Considerations for Managing Configuration Set Entries
Managing Server Configuration Set Entries by Using Oracle Directory Manager
Managing Server Configuration Set Entries by Using Command-Line Tools
The configuration set entry configset0 is the default, and is used as the template for all new configuration set entries. Although you can change values in the default configuration set, all of your changes are then carried over to every new configuration set entry that you create.
To change values that should not be in effect for every server instance, it is better to create new configuration set entries. Note that this applies to the Oracle directory server and Oracle directory integration server instances only. The Oracle replication directory server supports only one configuration set.
You may want to establish a separate instance of a directory server with different values. If you do not want those values to be exercised by all users, then set up a new configuration set entry and run a separate server instance pointing to that configuration set entry for groups with special needs.
Figure 5-1 shows three separate directory server instances, each with a different value.
Figure 5-1 shows:
An Oracle directory server (cn=odsldap) with:
One instance listening on the default port and using configset0 with SSL disabled
A second instance listening on the SSL port and using configset1 with SSL enabled
A replication server instance (cn=odsrepld) using configset0
|
Note: You can run multiple instances if the directory server is on the same computer. For example, you can run one instance in SSL mode and another in non-SSL mode. |
|
See Also:
|
You can use Oracle Directory Manager to view, add, modify, and delete configuration set entries.
|
Note: You cannot change the parameters for an active instance directly. Instead, you must change the parameters in a configuration set entry and save it. After the configuration set entry is saved, use the OID Control Utility restart command to stop current Oracle directory server instances and restart them.You can change a configuration set entry and start fresh instances that use the new parameters. The changes do not affect the older instances that are still running, however, unless they are restarted. For information on restarting directory server instances, see "Oracle Internet Directory Server Administration Tools" in Oracle Identity Management User Reference. |
This section contains the following topics:
Viewing Configuration Set Entries by Using Oracle Directory Manager
Adding Configuration Set Entries by Using Oracle Directory Manager
Modifying Configuration Set Entries by Using Oracle Directory Manager
Deleting Configuration Set Entries by Using Oracle Directory Manager
To view configuration set entries:
In the navigator pane, expand Oracle Internet Directory Servers, then directory server instance, then Server Management.
Select Directory Server, Replication Server, or Integration Server. The parameters of the active instance appear in the right pane.
In the right pane, select an instance, then choose View Properties. A Server Process dialog box appears.
You can see all the parameters for the instance by selecting the tabs across the top of the dialog box. However, you cannot change these parameters in this dialog box. To change them, you must change the configuration set entry on which they are based.
The first time you add a configuration set entry, you can:
Use the default configuration set as a template for the new configuration set entry, then copy from it to make subsequent configuration sets
Add a configuration set entry without copying from an existing one
To add configuration set entries by copying the default configuration set entry:
In the navigator pane, expand Oracle Internet Directory Servers, then directory server instance, then Server Management, then Directory Server.
Select Default Configuration Set.
On the toolbar, choose Create Like. The Configuration Sets dialog box displays the General tab page.
In the General tab page, fill in the fields. These are described in Table A-34.
Select the SSL Settings tab and fill in the fields. These are described in Table A-35.
Choose Apply.
Restart the server instance for the command to take effect.
|
See Also:
|
To create a new configuration set entry without copying from a previous configuration set entry:
In the navigator pane, expand Oracle Internet Directory Servers, then directory server instance, then Server Management, then Directory Server.
Select Default Configuration Set.
On the toolbar, choose Create. A Configuration Sets dialog box displays the General tab page.
In the General tab page, fill in the fields. These are described in Table A-34.
Select the SSL Settings tab and fill in the fields. These are described in Table A-35 .
Choose OK.
To modify configuration set entries:
In the navigator pane, expand each of the following objects in succession: Oracle Internet Directory Servers, directory server instance, Server Management, Directory Server.
Select the configuration set entry you want to modify. The configuration set appears in the group of tab pages in the right pane.
In the General tab page, modify the fields. These are described in Table A-34. To save the changes, choose Apply.
Select the SSL Settings tab and modify the fields. These are described in Table A-35. To save the changes, choose Apply.
Restart the server instance for the command to take effect.
|
See Also:
|
To delete configuration set entries:
In the navigator pane, expand each of the following objects in succession: Server Management, Directory Server.
Select the configuration set entry you want to delete.
On the toolbar, choose Delete.
Restart the server instance for the command to take effect.
Although changing configuration set entries by using Oracle Directory Manager is desirable, it can sometimes be more convenient to use the available command-line tools—for example, when you want to make the same set of changes across multiple Oracle directory servers.
When you add or modify configuration set entries by using the command-line tools, the input file for adding a new configuration set entry must be written in LDIF. It must contain only the attributes and values that differ from the installed defaults. The directory server uses the attribute values that you establish in the new configuration set entry to override its own existing values for these attributes.
|
See Also: "LDIF File Formatting Rules and Examples" in Oracle Identity Management User Reference for information on LDIF |
This section contains the following topics:
If you are adding a new Oracle directory server instance, then you can either use an existing configuration set entry, or add a new one for the new instance.
To add a new configuration set entry, create an input file, and then load the input file with ldapadd. Follow these steps:
Create the input file in a text editor.
Input files must use LDIF format. When you create the input file, you need to define or include only those attributes that differ from the current values in that configuration set entry.
In this example, the parameter configset2 is the RDN, or local name, of the new entry and the wallet location is: /HOME/test/wallet.
dn:cn=configset2, cn=osdldapd, cn=subconfigsubentry cn:configset2 objectclass:orclConfigSet objectclass:orclLDAPSubConfig objectclass:top orclsslauthentication:1 orclsslenable:1 orclsslport:5000 orclsslversion:3 orclsslwalleturl:file:/HOME/test/wallet
Run ldapadd with an input file.
At the system prompt, type the command to add the input file.
ldapadd [options] -f LDIF_file_name
|
See Also:
|
To modify or delete an existing configuration set entry, create an input file containing only the attributes that you want to change, and then load the input file with the ldapmodify command. Follow these steps:
Create the input file.
When you create the input file, define or include only those attributes that differ from the installed defaults.
Input files must have LDIF format.
In the next example, the parameter cn=configset2,cn=osdldapd,cn=subconfigsubentry is the DN, or local name, of an existing configuration set entry. This example shows how to modify the ORCLSSLPORT parameter to 7000.
dn:cn=configset2,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclsslport orclsslport: 7000
Run ldapmodify referencing the input file.
Type the command to reference the input file at the system prompt.
ldapmodify [options] -f LDIF_file_name
|
See Also:
|
An operational attribute—as opposed to an application attribute—pertains to the operation of the directory itself. Some operational information is specified by the directory to control the server—for example, the time stamp for an entry. Other operational information, such as access information, is defined by administrators and is used by the directory program in its processing. You must have super user privileges to set system operational attributes.
This section contains these topics:
Setting System Operational Attributes by Using Oracle Directory Manager
Setting System Operational Attributes by Using ldapmodify
You can view and set some of the operational attributes for each Oracle directory server to which you are connected by using Oracle Directory Manager. To do this, in the navigator pane, expand Oracle Internet Directory Servers, then select a directory server. System operational attributes appear in the right pane.
Table A-36 describes the fields displayed in Oracle Directory Manager for system operational attributes.
To modify system operational attributes, use ldapmodify. The "Oracle Identity Management LDAP Attribute Reference" in Oracle Identity Management User Reference describes the modifiable system operational attributes.
|
See Also: The "ldapmodify" command-line tool reference in Oracle Identity Management User Reference for a more detailed discussion of ldapmodify, and a list of its options |
To enable users to search for specific naming contexts, you can publish those naming contexts. This section contains these topics:
To publish a naming context, you specify the topmost entry of each naming context as a value of the namingContexts attribute in the root DSE. For example, suppose you have a DIT with three major naming contexts, the topmost entries of which are c=uk, c=us, and c=de. If these entries are specified as values in the namingContexts attribute, then a user, by specifying the appropriate filter, can find information about them by searching the root DSE. The user can then focus the search—for example, by concentrating on the c=de naming context in particular.
You can use either Oracle Directory Manager or ldapmodify to publish a naming context. The namingContexts attribute is multi-valued, so you can specify multiple naming contexts.
To search for published naming contexts, perform a base search on the root DSE with objectClass =* specified as a search filter. The retrieved information includes those entries specified in the namingContexts attribute.
Before you publish a naming context, be sure that:
You are a directory administrator with the necessary access to the root DSE
The topmost entry of that naming context exists in the directory
In the navigator pane, expand Oracle Internet Directory Servers and select the directory server on which you want to specify a naming context. The corresponding tab pages for that directory server appear in the right pane.
In the System Operational Attributes tab page, in the Naming Contexts field, enter the topmost DN of the naming context you want to publish. You can also choose Browse to open a search window.
Choose Apply.
This section contains these topics:
Managing Super Users, Guest Users, and Proxy Users by Using Oracle Directory Manager
Managing Super Users, Guest Users, and Proxy Users by Using ldapmodify
Table 5-1 defines super users, guest users, and proxy users.
You can use either Oracle Directory Manager or ldapmodify to administer the user names and passwords for each of these users.
Table 5-1 Definitions of Super User, Guest User, and Proxy User
| Type of User | Definition |
|---|---|
|
A special directory administrator with full access to directory information. The default user name of the super user is Note: Oracle recommends that you change the password immediately after installation. |
|
|
One who is not an anonymous user, and, at the same time, does not have a specific user entry. The default user name for a guest user is |
|
|
A user typically in an environment with a middle tier such as a firewall, an application such as Oracle Delegated Administration Services, or a RADIUS server. The default user name for a proxy user is See Also: "Indirect Authentication" for more information about proxy users |
|
Note: You can log on to the Oracle Directory Manager without giving a user name or password. If you do this, you have the privileges specified for an anonymous user. Anonymous users should have very limited privileges. |
|
Note: The passwords for super users, guest users, and proxy users are encrypted by default. You cannot modify them to send them in the clear. |
To set a user name or password for a super user, a guest user, or a proxy user by using Oracle Directory Manager:
In the navigator pane, expand Oracle Internet Directory Servers, then select a directory server. The group of tab pages for that server appear in the right pane.
Select the System Passwords tab. This page displays the current user names and passwords for each type of user. Note that passwords are not displayed in the password fields.
Edit the appropriate field in the System Passwords tab page as described in Table A-37. To save your changes, choose Apply.
To set or modify a user name or password for a super user, a guest user, or a proxy user, use ldapmodify to modify the appropriate attribute.
Table 5-2 Names, Passwords, and Attributes for Super, Guest, and Proxy Users
| User Name | Password | Attribute |
|---|---|---|
|
|
||
|
|
||
|
|
For example, to change the password of the super user to superuserpassword, use ldapmodify to modify the DSE by using an LDIF file containing the following:
dn: changetype:modify replace:orclsupassword orclsupassword:superuserpassword
|
See Also: The "ldapmodify" command-line tool reference in Oracle Identity Management User Reference for ldapmodify syntax and usage notes. |
The Oracle Directory Server can be configured to allow or disallow anonymous bind. This behavior is controlled by the orclAnonymousBindsFlag attribute of the root DSE entry. Table 5-3 lists the allowed values for orclAnonymousBindsFlag and the resulting directory server behavior.
Table 5-3 Orclanonymousbindflag Value and Directory Server Behavior
| orclAnonymousBindsFlag Value | Directory Server Behavior |
|---|---|
|
0 |
Disallows anonymous bind |
|
1 |
Allows anonymous bind (default) |
|
2 |
Allows anonymous bind but allows only search operations on root DSE entry for anonymous users |
By default, the directory server allows anonymous bind. That is, the orclAnonymousBindsFlag attribute is set to 1.
The following example shows how to disable anonymous bind using the ldapmodify command-line tool:
ldapmodify -h hostname -p port -D cn=orcladmin -w super_user_pwd <<EOF dn: changetype: modify replace: orclanonymousbindsflag orclanonymousbindsflag: 0 EOF
To view information about any active directory server instance—including type, instance number, debug level, host name, and configuration parameters—use Oracle Directory Manager. To do this:
In the navigator pane, expand Oracle Internet Directory Servers and select a directory server. The group of tab pages for that directory server instance appear in the right pane.
Select the Server Management tab. This displays basic information—namely, type, instance number, debug level, and host name—for all active directory server instances.
To see configuration parameters for a particular directory server instance, select the directory server instance, then choose View Properties. The Server Process dialog box displays configuration parameters for the directory server instance you selected. Note that you cannot change configuration parameters in this dialog box. To change them, you must change the configuration set entry on which they are based.
|
See Also: "Managing Server Configuration Set Entries by Using Oracle Directory Manager" for instructions on changing configuration set entries |
You can specify the number of minutes that LDAP connections remain idle before closing. To do this, you set a value for the orclLDAPconnTimeout attribute described in "Oracle Identity Management LDAP Attribute Reference" in Oracle Identity Management User Reference.
The Oracle Internet Directory uses a password when connecting to its own designated Oracle database. The default for this password when you install Oracle Internet Directory is the same as that for the Oracle Application Server administrator. You can change this password by using the OID Database Password Utility.
Because entries sometimes have distinguished names that are fairly long and cumbersome, Oracle Internet Directory makes it easier to administer them by using alias objects. When someone looks up—that is, references—an object by using an alias, the alias is dereferenced, and what is returned is the object to which the alias points. For example, the alias, Server1, can be dereferenced so that it points to the fully qualified DN—namely, dc=server1,dc=us,dc=myCompnay,dc=com. This feature also enables you to devise structures that are not strictly hierarchical.
This section provides examples of how to add, search for, and modify alias entries, and it includes a list of messages. It contains these topics:
An alias entry uses the object class alias to distinguish it from object entries in a directory. The definition of that object class is as follows:
(2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName)
An alias entry also contains the aliasedObjectName attribute that, in turn, contains the DN of the object to which it is pointing. The definition of that attribute is as follows:
(2.4.5.1 NAME 'aliasedObjectName" EQUALITY distinguishedNmameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE)
Figure 5-2 and the accompanying text provides an example of alias entry dereferencing.
In Figure 5-2, ou=uk sales,ou=global sales,o=myCompany,c=us is an alias entry pointing to the ou=sales,o=myCompany,c=uk entry.
When anyone references ou=uk sales,ou=global sales,o=oracle,c=us, the directory server automatically reroutes them to the real entry, ou=sales,o=oracle,c=uk.
This section contains these examples:
To add an alias entry, you create a normal entry in LDIF and an alias entry pointing to the real entry. Following the steps in this example produces the tree in Figure 5-3.
Create a sample LDIF file, My_file.ldif, with the following entries:
dn: c=us c: us objectclass: country dn: o=MyCompany, c=us o: MyCompany objectclass:organization dn: ou=Area1, c=us objectclass: alias aliasedObjectName: o=MyCompany, c=us dn: cn=John Doe, o=MyCompany, c=us cn: John Doe sn: Doe objectclass: person dn: cn=President, o=MyCompany, c=us objectclass: alias aliasedobjectname: cn=John Doe, o=MyCompany, c=us
Add these entries to the directory by using the following command:
ldapadd -p port -h host -f My_file.ldif
|
Note: When you add an alias entry whose parent is an alias entry, the directory server returns an error. |
Figure 5-3 Resulting Tree when Creating the My_file.ldif
In Figure 5-3, the letter A represents an alias entry, where:
ou=Area1 is an alias pointing to o=MyCompany
cn=President is an alias pointing to cn=John Doe
In each search you specify, there are flags you can set. The search is performed based on the flag you specify.
The flags pertaining to alias dereferencing are -a never and -a find.
By default, the dereference flag in ldapsearch is -a never and thus the directory server does not perform any dereferencing for alias entries.
A base search finds the top level of the alias entry you specify.
This example shows a base search of ou=Area1,c=us with a filter of "objectclass=*" with the dereferencing flag set to -a find.
ldapsearch -p port -h host -b "ou=Area1,c=us" -a find -s base "objectclass=*"
The directory server, during the base search, looks up the base specified in the search request and returns it to the user. However, if the base is an alias entry and, as in the example, -a find is specified in the search request, then the directory server automatically dereferences the alias entry and returns the entry it points to. In this example, the search dereferences ou=Area1,c=us, which is an alias entry, and returns o=MyCompany,c=us.
A one-level search finds only the child to the base level you specify.
This example shows a one-level search of "ou=Area1,c=us" with a filter of "objectclass=*" with the dereferencing flag set to -a find.
ldapsearch -p port -h host -b "ou=Area1,c=us" -a find -s one "objectclass=*"
The directory server performs the search in two steps.
It searches for the base that is specified in the search request.
When it locates the base, it looks up all one-level entries under this base and returns entries that match the filter criteria.
In the example, -a find is specified in the search request, and thus the directory server automatically dereferences while looking up the base (the first step), but does not dereference alias entries that are one level under the base. Therefore, the search dereferences ou=Area1,c=us, which is an alias entry, and then looks up one-level entries under o=MyCompany,c=us. One of the one-level entries is cn=President,o=MyCompany,c=us that is not dereferenced and is returned as is.
Thus, the search returns cn=President,o=MyCompany,c=us and cn=John Doe,o=MyCompany,c=us.
A subtree search finds the base, children, and grand children.
This example shows a subtree search of "ou=Area1,c=us" with a filter of "objectclass=*" with the dereferencing flag set to -a find.
ldapsearch -p port -h host -b "ou=Area1,c=us" -a find -s one "objectclass=*"
The directory server performs the search in two steps.
It searches for the base that is specified in the search request.
When it locates the base, then it looks up all entries under this base and returns entries that match the filter criteria.
In the example, -a find is specified in the search request, and thus the directory server automatically dereferences while looking up the base (the first step), but does not dereference alias entries that are under the base. Therefore, the search dereferences ou=Area1,c=us, which is an alias entry, and then looks up entries under o=MyCompany,c=us. One of the entries is cn=President,o=MyCompany,c=us that is not dereferenced and is returned as is.
Thus, the search returns:
o=MyCompany,c=us
cn=john doe,o=MyCompany,c=us
cn=President,o=MyCompany,c=us
This example shows how to modify alias entries. It creates a sample LDIF file, My_file.ldif with following entries:
dn: cn=President, o=MyCompany, c=us changetype : modify replace: aliasedobjectname aliasedobjectname: cn=XYZ, o=MyCompany, c=us
Modify the alias entry using the following command:
ldapmodify -p port -h host -f My_file.ldif
Table 5-4 lists the messages related to alias entry dereferencing and the corresponding meaning for each message.
Table 5-4 Entry Alias Dereferencing Messages
| Message | Meaning |
|---|---|
|
Alias Problem |
Either of the following have occurred:
|
|
Alias Dereferencing Problem |
The user cannot dereference an alias because of access control issues. |
|
No Such Object |
The server cannot find the base DN specified in the search request. |
|
Invalid DN Syntax |
When adding or modifying an alias entry, if the value specified for |
|
Success |
The client operation successfully completes. When the dereferenced target does exist but does not match the filter specified in the search request, the server returns a success message with no matched entry. |
|
Insufficient Access Rights |
The user does not have access to the dereferenced entry. |
To perform an operation on a particular entry, a client must be able to find the server in which that entry resides. In a distributed environment, information about the location of a server can be available in one of two ways:
Statically, in the directory server usage file (ldap.ora) stored on the client host
Dynamically, by using the domain name system (DNS). In this case, the information about server location is stored and managed in a central domain name server. The client, at request processing time, retrieves this information from the domain name server dynamically.
This section discusses these two methods of locating server information. It contains these topics:
Static Directory Server Discovery by Using the Directory Server Usage File (ldap.ora)
Dynamic Directory Server Discovery by Using the Domain Name System (DNS)
|
See Also:
|
Using this method, when a client seeks to perform an operation on a directory entry, it obtains directory server location information from the directory server usage file (ldap.ora) stored on the client host. This file contains configuration parameters that specify:
The type of directory server—for example, Oracle Internet Directory, Microsoft Active Directory, SunONE Directory Server, and so forth
The location of the directory server
The default directory entry that the client or server will use to look up or configure connect identifiers for connections to database services
The file ldap.ora resides in the file system of the LDAP client. The client looks for this file in the following file system directories, in order of precedence:
The directory pointed to by the LDAP_ADMIN environment variable
The directory ORACLE_HOME/ldap/admin (or, on Microsoft Windows, ORACLE_HOME\ldap\admin)
The directory pointed to by the TNS_ADMIN environment variable
The directory ORACLE_HOME/network/admin (or, on Microsoft Windows, ORACLE_HOME\network\admin)
If the file ldap.ora is present in more than one location, then the location having higher precedence is honored.
Using the static method to discover a directory server can increase management overhead. For example, because the ldap.ora file is stored on the client host, the administrator must update that file on every client whenever the host name or port number of a directory server is changed. To avoid this increased overhead, you can enable an application to discover directory servers dynamically by using the domain name system (DNS).
The domain name system (DNS) is a dynamic way of locating domain names and translating them into the actual addresses of computers. This translation process is handled by a central domain name server, which contains information about the locations of directory servers.
Once a network administrator has entered the necessary information about directory server locations in a domain name server, clients can retrieve that information from that server instead of from ldap.ora files.
For a client to locate a directory server by using DNS, the following steps must have been completed:
The network administrator must have entered a DNS Service Location Record (SRV) into the domain name server.
The client application must have been enabled to map distinguished names to domain names.
To find the directory server on which an entry resides, a client communicates with the domain name server. Specifically, it provides to the domain name server a domain name. The domain name specifies where the needed directory server is located.
To generate the domain name, the client extracts the domain component from the DN entered by the user. For example, in the DN cn=John Doe,ou=accounting,dc=example,dc=net, the domain component is dc=example,dc=net. That domain component represents the server on which the requested entry resides. The client then converts that domain name component to a domain name in a format recognized by the domain name server, namely, example.net.
Figure 5-4 and the accompanying text show the process of locating a directory server from the perspective of a client.
A user wanting to perform an operation on a directory entry, enters into the client the distinguished name (DN) of that entry—for example, cn=John Doe,ou=accounting,dc=example,dc=net.
To communicate with the domain name server, the client converts the domain component of the DN to a domain name. In the example used here, the client would convert the domain component of that DN—namely, dc=example,dc=net—to the domain name example.net.
The client queries the domain name server for SRV resource records having the specified domain name.
The domain name server returns the SRV resource records that match the specified domain name. These resource records contain the host name information of the directory server containing the requested entry. If the domain name server is not able to find any matching SRV resource records, then it returns an error message.
The client parses the records. It extracts the directory host name information from these records and returns it to the user.
|
See Also:
|
|
Note: The domain name server either stores all the necessary SRV records locally, or obtains them from other domain name servers. If the domain name server cannot find the requested information, then it returns an error message. It does not return a referral to another domain name server. |
Registering server location information for a directory server involves entering a DNS service location record (SRV) into the domain name server. The SRV record contains:
The DNS name of the server that provides the LDAP service
The corresponding port number
Parameters that enable the client to choose an appropriate server from multiple servers
The SRV resource record enables administrators to use several servers for a single domain, to move services from host to host easily, and to designate some hosts as primary servers for a service and others as backups.
The format of the SRV record can be either specific to Oracle Internet Directory servers or standard. For information about Oracle Internet Directory servers, the Oracle Internet Directory-specific format is preferred. When a client first queries a domain name server, it looks for SRV records that have the Oracle Internet Directory-specific format. If it does not find any with this format, then it queries for SRV records that have the standard format.
The Oracle Internet Directory-Specific Format for SRV Records
The Oracle Internet Directory-specific format is:
_Service._Proto._product.Domain TTL Class Type Priority Weight Port Target
Table 5-5 describes the arguments. The following is an example of an SRV record that uses the Oracle Internet Directory-specific format.
_ldap._tcp._oid.acme.com 0 IN SRV 0 1 389 ldap.acme.com
The Standard Format for SRV Records
The standard format is:
_Service._Proto.Domain TTL Class Type Priority Weight Port Target
Table 5-5 describes the arguments. The following is an example of an SRV record for a non-SSL-based directory server that uses the standard format.
_ldap._tcp.acme.com 0 IN SRV 0 1 389 ldap.acme.com
Table 5-5 Arguments in a Service Location Record (SRV)
| Argument | Description |
|---|---|
|
Service |
For a non-SSL-based server, the value for this argument is |
|
Proto |
The value is always |
|
Product |
The value is always |
|
Domain |
The domain name. It is usually obtained by converting the DN of the naming context mastered by the directory server into a domain name. See Also: "How a Client Locates a Directory Server by Using DNS" |
|
TTL |
Time to live. This argument has the standard DNS meaning. It specifies how long the resource record may be cached before the source of the information is again consulted. |
|
Class |
This argument has the standard DNS meaning. SRV records occur in the IN class. |
|
Type |
For all SRV records, the value for this argument is SRV. |
|
Priority |
The priority of the directory server. A client must attempt to contact the target host with the lowest-numbered priority. |
|
Weight |
A server selection mechanism, this argument specifies a relative weight for entries with the same priority. If multiple SRVs have the same priority, then they are ordered according to the following protocol:
|
|
Port |
The port on target host for the directory service. |
|
Target |
The domain name of the host on which the directory server is running. |
|
Note: If the directory server is moved to a different host or is run on different port, then the corresponding SRV resource record must be updated accordingly. |
