This documentation applies to the 8.0 version of Remedy Action Request System, which is in "End of Version Support." You will not be able to leave comments.

To view the latest version, select the version from the Product version menu.

Resolving certificate issues

The general approach to resolving certificate issues in BMC Remedy AR System includes:

Preventing common issues

To avoid common problems with certificates, ensure that:

  • The Issuer and Subject in your Secure Socket Layer (SSL) certificate are resolvable. The Issuer and Subject are in distinguished name format at times.
  • Your SSL certificate(s) reside(s) in the certificate database.
  • For every link in the certificate chain:
    • The domain is known.
    • The Issuer is a recognized and trusted Certificate Authority (CA). Your LDAP plug-in must trust the certificate from your LDAP server. This means that your CA, such as VeriSign, must provide a known root certificate before the LDAP plug-in will trust the certificate.
  • All failover devices in your environment contain functioning certificates.

Identifying certificate issues

To establish an SSL connection for external authentication, credentials are exchanged between the BMC Remedy AR System server and an LDAP server. The AR System server must verify the credentials sent by the LDAP server with the requirement that the certificate database on the AR System server contain the CA certificate used to generate the LDAP server certificate.

Some issues that can occur when a validated certificate is used to establish an SSL connection between the AR System server and an LDAP server. You should check to make sure that your installation is free from these problems:

  • An incorrect NSS library version or patch was used to generate a certificate. You must use the correct NSS libraries. For information about library versions, see NSS library support.
  • The LDAP server is not configured to use SSL.
  • The SSL port is closed.
  • Your LDAP server's CA certificate is:
    • Not found in the certificate database
    • Either expired or is not appropriate. For example, a client certificate might be used as a CA certificate.
  • BMC Remedy AR System does not receive the certificate when required.
  • The LDAP server certificate is not imported.

Follow these steps to verify that AR System is properly configured with the LDAP server for SSL connections:

  1. Open the web browser on the AR System server and enter: https://<LDAP server address>
  2. When asked, choose to accept the certificate.
  3. Enter this command for information about a validated certificate:
    
    certutil -L -d <certificate databaselocation> <certname>
    

Determining the associated forms and fields

Make sure that the AR System External Authentication (AREA) LDAP and AR System Database Connectivity (ARDBC) LDAP Configuration forms are configured correctly so that AR System can establish SSL connections to the LDAP server. Ensure that:

  1. Secure Socket Layer is set to Yes.
  2. The correct certificate database directory path is entered in the Certificate Database field.
  3. The same user name and password can be used to log in to any application that supports the LDAP protocol.
    AREA LDAP Configuration form
    (Click the image to expand it.)


    ARDBC LDAP Configuration form
    (Click the image to expand it.)

See the AREA LDAP plug-in and ARDBC LDAP plug-in information in the Integrating section to configure the AREA LDAP and ARDBC LDAP plug-ins.

Isolating the problem

To obtain more detailed information about the SSL communication between the AR System server and the LDAP server, use the SSL debugging tools SSLDEBUG and SSLTRACE.

Note

You can also use the SSLTAP debugging tool to debug. For more information see http://www.mozilla.org/projects/security/pki/nss/tools/ssltap.html

To send debugging information to standard output

  1. Edit the armonitor.conf file and prefix the arplugin line with a hash symbol (#) to comment it out.
  2. Restart the AR System server so that the plug-in server is no longer running.
  3. From the command line, change to the directory where arserverd and arplugin are located.
  4. From the command line, enter the following:
    For UNIX
    
    SSLDEBUG=1;export SSLDEBUG
    SSLTRACE=3;export SSLTRACE
    
    For Microsoft Windows
    
    SET SSLDEBUG=1
    SET SSLTRACE=3
    
  5. From the command line, enter the following to launch the plug-in server:
    For UNIX
    
    ./arplugin -i <server_installation_directory>
    
    For Windows
    
    arplugin -i . -m
    
  6. Enable the plug-in log file:
    1. In the AR System Administration console, click System > General > Log Files.
    2. Select Plug-In Log.
    3. Set the log level to All.
  7. Perform some user actions that would cause an LDAP connection using SSL to take place.

    If an SSL connection to the LDAP host was processing, the command prompt should contain diagnostic information such as an error number. This error number may be used by your SSL administrators to troubleshoot the problem. In some cases, a descriptive error message is also provided.

Examining the plug-in log

The plug-in server log can track the events of the AREA and ARDBC LDAP plug-ins that AR System uses. Each line of a plug-in log file begins with an <PLGN> prefix. Each entry includes information such as the time stamp, the API calls encountered, and name of the plug-in. Here's a section from a plug-in log:


<PLGN> <TID: 0000002944> <RPC ID: 0000000000> <Queue: Dispatcher>
<Client-RPC: 000000> /* Fri Apr 21 2011 15:56:41.6300 */ Plug-in Trace Log -- ON
<PLGN> <TID: 0000002944> <RPC ID: 0000000000> <Queue: Dispatcher>
<Client-RPC: 000000> /* Fri Apr 21 2011 15:56:41.6460 */ AREA&nbsp;
Plug-in Loaded: EXAMPLE.AREA.SIMPLE version 1

Checking certificates

  1. From the command line, enter:
    
    certutil.exe -L -d C:\CertUser\ldap\Sequoia
    
       Acme CT,P,P
       VeriSign CT,P,P
  2. Enter the following and ensure that subject corresponds to the name of the LDAP server and that a separate certificate exists for the Issuer.
    
    certutil.exe -L -n VeriSign -d C:\CertUser\ldap\Sequoia
    where
    • -d certDir specifies the directory that contains the database certificate.
    • -L generates a list.
    • -n nickname specifies the nickname of the certificate. If the nickname contains spaces, enclose it in double quotation marks.
    • CT,P,P are the trust attributes. C signifies a trusted CA to issue server certificates and implies a valid CA. T signifies a trusted CA to issue client certificates and implies a valid peer.

      Certificate information

      Option

      Description

      Common Name (CN)

      VeriSign (Issuer) Acme (Subject)

      Organizational Unit (OU)

      Shared Services

      Organization (O)

      Sequoia Institute

      Location (L)

      Sopia Landing

      State (ST)

      New York

      Country (C)

      US

      
      Certificate:
          Data:
              Version: 3 (0x2)
              Serial Number:
                  53:19:a1:ae:00:00:00:00:57:d9
              Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
              Issuer: "CN=VeriSign,OU=Shared Services,O=Sequoia Institute,L=Sopia Landing,ST=New York,C=US"
              Validity:
                  Not Before: Thu Oct 14 13:12:02 2011
                  Not After : Sat Oct 13 13:12:02 2012
              Subject: "CN=Acme,OU=Domain Controllers,DC=am,DC=Sequoia,DC=com"

Examining SSL debugging logs

A sample log file, used when debugging certificate problems on UNIX with SSLDEBUG and SSLTRACE, is shown in Example output. A sample verbose log file is shown in Example verbose output. The detailed debugging log is only available if you use the compiled version of the NSS libraries from BMC. If you require this compiled version, contact your BMC Support representative.

Example debug output

The example standard output shown here does not require the BMC-compiled version of the NSS libraries. To display this output, follow the procedure in step 3, Isolate the problem.

Sample debugging output includes the following key areas:

  • Successful initiation of the SSL handshake, which demonstrates AR System is attempting to establish a connection to your LDAP server.
    
    6408: SSL[10538544]: sending client-hello
    6408: SSL3[10538544]: handle server_hello handshake
    6408: SSL3[10538544]: Set XXX Pending Cipher Suite to 0x000a
  • Information that shows the plug-in server received the certificate from the LDAP server.

    Important

    AR System must verify the peer certificate. It is critical that this certificate reside in the SSL certificate database or be resolvable through a certificate chain.

    
    6408: SSL3[10538544]: Peer Certificate Issuer:[CN=idd-corporate-usa-02-CA,DCidd,DC=com]
  • Successful completion of the LDAP handshake.
    
    6408: SSL3[10538544]: handle finished handshake
    6408: SSL[10538544]: handshake is completed
  • Verification of the Administrator user from the AREAVerifyLoginCallback API call.
    
    <PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:24.9790 */+VL    AREAVerifyLoginCallback -- user Administrator
    
    <PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:24.9790 */<ARSYS.AREA.LDAP> <FINEST> AREAVerifyLoginCallback
    
  • Validation that the AREA plug-in has established a connection with the LDAP server (usa-02.idd.com). In this example, the LDAP server authentication is enabled on port 636, and the SSL certificate used to secure the connection resides in the /OPT/ARSystem/LDAP/SSL/cert directory.
    
    <PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:24.9790 */<ARSYS.AREA.LDAP> <FINER> Connecting via SSL(host=HOSTNAME-usa-02.idd.com, port=636, certPath=OPT/ARSystem/LDAP/SSL/cert with Server SSL Authentication enabled
    
  • Confirmation that the AREA plug-in bind to the LDAP server is successful.
    
    <PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2120 */<ARSYS.AREA.LDAP> <FINEST> Successful bind as user Administrator
    
  • Confirmation that the AREA plug-in authentication on the LDAP server is successful.
    
    <PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2250 */-VL                                  OK
    <PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:24.9790 */<ARSYS.AREA.LDAP> <FINEST> AREAVerifyLoginCallback

Example verbose output


Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
idd-corporate-usa-02-CA CT,P,P

Debug snippet
SSL: tracing set to 3
SSL: debugging set to 1
6408: SSL[10538544]: sending client-hello
6408: SSL3[10538544]: handle server_hello handshake
6408: SSL3[10538544]: Set XXX Pending Cipher Suite to 0x000a
6408: SSL3[10538544]: handle certificate handshake
6408: SSL3[10538544]: Peer Certificate Issuer:[CN=idd-corporate-usa-02-CA,DCidd,DC=com]
6408: SSL3[10538544]: handle certificate_request handshake
6408: SSL3[10538544]: handle server_hello_done handshake
6408: SSL3[10538544]: send client_key_exchange handshake
6408: SSL3[10538544]: DONE sending client_key_exchange
6408: SSL3[10538544]: send change_cipher_spec record
6408: SSL3[10538544] SendRecord type: handshake  (22) nIn=269
6408: SSL[10538544]: Send record (plain text) [Len: 269]
.
.
.6408: SSL3[10538544] SendRecord type: change_cipher_spec (20) nIn=1
6408: SSL[10538544]: Send record (plain text) [Len: 1]
   01                                                .
6408: SSL3[10538544] Set Current Write Cipher Suite to Pending
6408: SSL3[10538544]: send finished handshake
6408: SSL3[10538544] SendRecord type: handshake  (22) nIn=16
6408: SSL[10538544]: Send record (plain text) [Len: 16]
   14 00 00 0c bc 24 c1 f7 e0 3f aa db 35 72 5e 8a   .....$...?..5r^.
6408: SSL3[10538544]: handle change_cipher_spec record
6408: SSL3[10538544] Set Current Read Cipher Suite to Pending
6408: SSL3[10538544]: handle finished handshake
6408: SSL[10538544]: handshake is completed
6408: SSL[10538544]: SecureSend: sending 65 bytes
6408: SSL3[10538544] SendRecord type: application_data (23) nIn=65
6408: SSL[10538544]: Send record (plain text) [Len: 65]
.
.
.
6408: SSL[10538544]: recving 22 bytes securely (errno=0)
6408: SSL[10538544]: SecureSend: sending 85 bytes
6408: SSL3[10538544] SendRecord type: application_data (23) nIn=85
6408: SSL[10538544]: Send record (plain text) [Len: 85]
   kjdsf;lajsdflaj
CATHERINE
DC=idd
   2c 44 43 3d 63 6f 6d 80 08 54 68 72 65 65 32 23   ,DC=com..Three2#
   30                                                0
6408: SSL[10538544]: recving 22 bytes securely (errno=0)
6408: SSL[10538544]: SecureSend: sending 65 bytes
6408: SSL3[10538544] SendRecord type: application_data (23) nIn=65
6408: SSL[10538544]: Send record (plain text) [Len: 65]
6408: SSL[10538544]: recving 22 bytes securely (errno=0)
6408: SSL[10538544]: SecureSend: sending 7 bytes
6408: SSL3[10538544] SendRecord type: application_data (23) nIn=7
6408: SSL[10538544]: Send record (plain text) [Len: 7]
   30 05 02 01 05 42 00                              0....B.
6408: SSL3[10538544]: send alert record, level=1 desc=0
6408: SSL3[10538544] SendRecord type: alert      (21) nIn=2
6408: SSL[10538544]: Send record (plain text) [Len: 2]
   01 00                                             ..
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:24.9790 */+VL    AREAVerifyLoginCallback          -- user Administrator
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:24.9790 */<ARSYS.AREA.LDAP> <FINEST> AREAVerifyLoginCallback
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:24.9790 */<ARSYS.AREA.LDAP> <FINER> Connecting via SSL(host=HOSTNAME-usa-02.idd.com, port=636, certPath=OPT/ARSystem/LDAP/SSL/cert with Server SSL Authentication enabled)
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.0460 */<ARSYS.AREA.LDAP> <FINER> connect timeout previously: -1
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.0460 */<ARSYS.AREA.LDAP> <FINER> connect timeout used: 35000
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.0460 */<ARSYS.AREA.LDAP> <FINER> ldap_simple_bind("CN=Administrator,CN=Users,DC=idd,DC=com", hidden)
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.1850 */<ARSYS.AREA.LDAP> <FINEST> After the bind
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.1850 */<ARSYS.AREA.LDAP> <FINER> ldap_search_ext("CN=Users,DC=idd,DC=com", 2, "samAccountname=Administrator")
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2020 */<ARSYS.AREA.LDAP> <FINER> ldap_simple_bind("CN=Administrator,CN=Users,DC=idd,DC=com", hidden)
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2120 */<ARSYS.AREA.LDAP> <FINEST> Successful bind as user Administrator
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2120 */<ARSYS.AREA.LDAP> <FINER> ldap_simple_bind("CN=Administrator,CN=Users,DC=idd,DC=com", hidden)
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2210 */<ARSYS.AREA.LDAP> <FINEST> User attribute: objectClass
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2210 */<ARSYS.AREA.LDAP> <FINEST> User attribute: cn
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2220 */<ARSYS.AREA.LDAP> <FINEST> User attribute: description
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2220 */<ARSYS.AREA.LDAP> <FINEST> User attribute: userCertificate
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2220 */<ARSYS.AREA.LDAP> <FINEST> User attribute: distinguishedName
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2220 */<ARSYS.AREA.LDAP> <FINEST> User attribute: instanceType
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2220 */<ARSYS.AREA.LDAP> <FINEST> User attribute: whenCreated
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2220 */<ARSYS.AREA.LDAP> <FINEST> User attribute: whenChanged
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2220 */<ARSYS.AREA.LDAP> <FINEST> User attribute: uSNCreated
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2220 */<ARSYS.AREA.LDAP> <FINEST> User attribute: memberOf
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2220 */<ARSYS.AREA.LDAP> <FINEST> User attribute: uSNChanged
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2220 */<ARSYS.AREA.LDAP> <FINEST> User attribute: name
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2220 */<ARSYS.AREA.LDAP> <FINEST> User attribute: objectGUID
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: userAccountControl
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: badPwdCount
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: codePage
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: countryCode
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: badPasswordTime
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: lastLogoff
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: lastLogon
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: logonHours
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: pwdLastSet
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: primaryGroupID
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: objectSid
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: adminCount
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2230 */<ARSYS.AREA.LDAP> <FINEST> User attribute: accountExpires
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2240 */<ARSYS.AREA.LDAP> <FINEST> User attribute: logonCount
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2240 */<ARSYS.AREA.LDAP> <FINEST> User attribute: sAMAccountName
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2240 */<ARSYS.AREA.LDAP> <FINEST> User attribute: sAMAccountType
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2240 */<ARSYS.AREA.LDAP> <FINEST> User attribute: servicePrincipalName
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2240 */<ARSYS.AREA.LDAP> <FINEST> User attribute: objectCategory
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2240 */<ARSYS.AREA.LDAP> <FINEST> User attribute: isCriticalSystemObject
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2240 */<ARSYS.AREA.LDAP> <FINEST> User attribute: dSCorePropagationData
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2250 */<ARSYS.AREA.LDAP> <FINE> Found valid user
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2250 */<ARSYS.AREA.LDAP> <FINER> LicenseMask=0 LicenseWrite=0 LicenseFTS=0 LicenseReserved1=0 Notification=3 Email=<NULL> LoginStatus=0 ModificationTime=0
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2250 */<ARSYS.AREA.LDAP> <FINER> Groups=<NULL>
<PLGN> <TID: 007056> <RPC ID: 0000000001> <Queue: AREA> <Client-RPC: 390695> /* Wed Oct 27 2011 14:14:25.2250 */-VL                                  OK

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Comments