Novell is now a part of Micro Focus

Troubleshooting Novell iChain 2.1 Authorization Issues

Articles and Tips: article

Neil Cashell
iChain WWS Engineer
Novell, Inc.
ncashell@novell.com

Shane Johns
iChain WWS Engineer
Novell, Inc.
sjohns@novell.com

01 Oct 2002


This AppNote discusses the interfaces and control flow of iChain 2.1's authorization components. It provides a list of available troubleshooting tools and discusses the most common iChain support issues, giving numerous tips to help address issues discovered when working with these iChain components. It is a follow-up to "Troubleshooting Novell iChain 2.1 Authentication Issues" AppNote in the September 2002 issue.


Topics

iChain, troubleshooting, LDAP, security, Web application developments

Products

Novell iChain 2.1

Audience

network administrators, integrators, developers

Level

intermediate

Prerequisite Skills

familiarity with Web applications and security

Operating System

n/a

Tools

none

Sample Code

no

Introduction

In a previous AppNote (see "Troubleshooting Novell iChain 2.1 Authentication Issues" in the September 2002 issue of Novell AppNotes, available online at http://support.novell.com/techcenter/articles/ana20020901.html), we explained how troubleshooting a system with many interacting components, such as Novell's iChain 2.1, can be challenging without the proper know-how and tools. That AppNote discussed the interfaces and flow control of iChain's authentication components and gave tips for resolving the most common authentication-related issues.

This AppNote picks up where the previous one left off, covering the interfaces and flow control of iChain's authorization components. It lists the tools that are available for troubleshooting authorization-related issues, and then provides numerous tips for resolving the most common iChain support issues.

Most people configuring iChain for the first time will encounter the infamous "403 Forbidden" alert on the browser when trying to access resources they should have access to. For the most part, especially when the 403 alert is qualified by the "Organizational policies prohibit access to this page" message, this is the result of the access control (ACLCHECK) module denying access to the URL for that user. This AppNote contains information on the way ACLCHECK interfaces into the Proxy, as well as the ACLCHECK rule processing algorithm. Once you are familiar with these concepts, troubleshooting authorization issues will hopefully become straightforward.

Authorization (ACLCHECK) Interfaces

This section provides detailed information about the interfaces between ACLCHECK and other iChain components.

PROXY.NLM

PROXY.NLM checks all incoming requests to see whether the protected resource a user is trying to access is Secured. In cases where it is Secured, control is passed to ACLCHECK to determine whether the user has access rights to the resource. If the protected resource is defined as Public or Restricted, no access control is performed on the request by ACLCHECK. Proxy then waits for a Deny or Allow response from ACLCHECK.

  • If a Deny response is sent back to the Proxy, the Proxy returns a "403 Forbidden" message to the browser, claiming that organizational policies have prohibited access to the page.

  • If an Allow response is sent from ACLCHECK, the Proxy continues with the processing of the request (that is, it forwards the request to the origin server or pulls the response from cache).

PROXYCFG.NLM

ACLCHECK uses LDAP requests to pull the relevant authorization information out of eDirectory. This LDAP information (bind username and password, IP address, and TCP port LDAP server listens on) is stored as part of the ACLCHECK authentication profile. The PROXYCFG.NLM module stores all configured authentication profiles, including this ACLCHECK one. LDAP configuration and communication errors may also be registered (and displayed) by PROXYCFG.

LDAPSDK.NLM

This NLM is used to generate the LDAP bind and search requests used by ACLCHECK, and to process the responses.

When ACLCHECK loads, it automatically creates ten LDAP connections (by default) by issuing ten LDAP Bind requests to the LDAP server. This is for performance reasons, so that the LDAP search requests can be piggy-backed on the existing connections.

When trying to verify whether or not a user has rights to access a protected resource, LDAP search requests are performed to determine whether the user, the user's container, or groups the user belongs to have access to the resource.

ACLCHECK.NLM

When Proxy determines that access control is required, it passes the username and the destination URL to ACLCHECK.NLM. ACLCHECK goes through its list of rules to verify whether the user has rights to access that URL.

  • If no matching rule is found, the user is denied access and the Deny return code is sent back to the proxy.

  • If a matching rule is found, grant the user access to the resource by sending an Allow response back to the proxy.

Authorization Flow Control

When ACLCHECK is passed a username and destination URL from the Proxy server, it first checks its hash tables to see whether or not a hashed entry already allows access to the URL for that user. ACLCHECK maintains two hash tables that link:

  • eDirectory objects (User, Group, and Organizational Unit) and the configured ACL Rules

  • The authenticated Users and the Groups they belong to

If a hashed entry exists that grants access to this user, ACLCHECK returns the Allow response to the Proxy. If no match is found in the hash tables, ACLCHECK must process the ACLCHECK rules in the eDirectory to locate a match. This is done in the following manner:

  1. Using an LDAP search request, verify whether the authenticated users container has a brdsrvsRuleObject attribute associated with it. This attribute contains the name of the Rule object.

    Note that during the configuration of a rule object in ConsoleOne, adding an NDS user, container, or group to the Rule object's "apply to" list automatically adds the BrdsrvsRuleObject attribute to that user, container, or group.

  2. Using an LDAP search request, read the rules from the Rule object. The returned rules define what paths within the protected resource that container can access.

  3. Check whether a matching rule exists that grants the user's container access to the URL.

  4. If no match exists, return to step 1 above and try to locate a Rule object for each of the user's groups. If no match is found granting access at this level, check to see whether a Rule object exists that specifically grants access for that user to the protected resource.

    Note that if ACLCHECK is loaded with the "/M" option for Community support, the rules are processed in the following order:

    • Rules on User's OUs (container)

    • Rules on User's OUs' Communities

    • Rules on User's Groups

    • Rules on User's Groups' Communties

    • Rules on the User

    • Rules on the User's Communities

    ACLCHECK can also be loaded with the "/Q" option to check query-based ACLs first, before checking the standard rules.

  5. Once a Rule object is located that will allow access to the URL for that user, ACLCHECK returns an Allow response to the Proxy and exits. No other rules are checked after a match is found.

  6. If all rules are checked and no match found, then access for this user is denied. The Deny response is returned to the Proxy, which in turn generates a "403 Forbidden" error to the browser.

  7. If query-based (dynamic) ACL rules are enabled, query these rules using the following algorithm:

    • Compare the incoming URL with URLs from all query-based ACLs to make sure that it is a URL for which a match is needed.

      If there is a match, check the URL exception list to see if it is okay to proceed with this destination URL.

    • Check if this user has any query-based rules in the cache.

      If so, check if that query was satisfied (CHECK_MATCH).

      • Match the username from the hash table with an NDS user.

      • Check to see if the cache entry is still valid (is the Time To Live, or TTL, greater than 0?).

      • If a match exists, return CHECK_MATCH; otherwise return CHECK_NOT_MATCH.

    • If there are no rules in the cache, send an LDAP query.

      Cache the LDAP response (cache matched, not matched, no attribute, and no object errors too!) The cache links the user and a rule, and the TTL verifies whether the entry is active or stale.

      Any change in the user's query-based attributes will not register until the TTL has expired, or unless an ACLCHECK REFRESH command is executed to clear the cache entries immediately. For example, suppose you have a dynamic query ACL that allows access to some application as long as the user's manager attribute is set to "true". A user whose manager attribute is set to "false" tries to get to the application and receives a "403 Forbidden" error. The user calls the Help Desk and the technician changes the user's manager attribute to "true". However, if the TTL is set to 15 minutes on the ACL, the user won't have access for 15 minutes unless a refresh is done of the ACLCHECK cache.

Tools for Troubleshooting Authorization Issues

Most of the tools that are used in the analysis of iChain authorization problems were discussed in the previous AppNote referenced above. In addition to general tools such as ConsoleOne, the ICE utility, DSTRACE, LDAP browsers, LSEARCH.NLM, the iChain Proxy Server GUI utility, and others, there are a few other useful tools that are specifically for troubleshooting ACLCHECK issues.

Debug Build of ACLCHECK

A debug build of ACLCHECK.NLM is available from Novell Technical Support that will give more information than the standard shipping version when the "/D4" option is enabled. This debug build logs information regarding cache access, hash table lookups, alias creations, thread information, and LDAP handle processing. This information can be useful in cases where no LDAP requests seem to be going out on the wire.

An example of some more advanced debug information is shown here:

ACL: 0: GetLDAPConnection: Enter ACL: 0: GetLDAPConnection: Error Free Exit ACL: 9: Attempting to connect to server: 147.2.16.114,uname=cn=admin; o=ctx,pwd=admin ACL: 0: GetLDAPConnection: Enter ACL: 0: GetLDAPConnection: Error Free Exit ACL: 0: Exiting OpenLDAPHandlePool ACL: 0: Entering GetAndProcessISOObject ACL: 0: Entering readMultiValueStringAttr_NDAP for DN= ICS_SERVER.ics, with attribute = ichainServiceHost ACL: 0: GetNDSConnection: Doing LoginAsServer ACL: 0: Exiting readMultiValueStringAttr_NDAP ACL: 0: Entering readMultiValueAttr for DN= CN=ISO21,O=ctx, with attribute=ichainProtectedResource ACL: 0: Entering GetLDAPHandleFromPool ACL: 0: Exiting GetLDAPHandleFromPool: Handle: 0 ACL: 0: Entering ReleaseLDAPHandle to free location 0 with error 0 ACL: 0: Exiting ReleaseLDAPHandle ACL: 0: Exiting readMultiValueAttr: rcode=0 ACL: 0: Entering into parseProtectedResourceStringAttr ACL: 0: Protected Resource = paddy, URL Prefix = http://ichain2.paddy.com/ ACL: 0: Protected Resource = nps2, URL Prefix = http://nps2.linny.com/ ACL: 0: Exiting from parseProtectedResourceStringAttr ACL: 0: Clearing Memory For String Attribute ACL: 0: Entering readQueryBasedACLRuleList ACL: 0: Entering readMultiValueAttr for DN= CN=ISO21,O=ctx, with attribute=iChainDynamicACLRules ACL: 0: Entering GetLDAPHandleFromPool ACL: 0: Exiting GetLDAPHandleFromPool: Handle: 0 ACL: 0: Entering ReleaseLDAPHandle to free location 0 with error 0 ACL: 0: Exiting ReleaseLDAPHandle ACL: 0: Error in 'ldap_get_values()': 84 ACL: 0: Exiting readMultiValueAttr: rcode=84 ACL: 0: Exiting GetAndProcessISOObject ACL: 0: Mutex is Unlocked... ACL: 0: Exiting from userGroupEventProcedure

ACLCHECK Logs

When a matching rule is found in the Rule object, ACLCHECK will log information in text file. The information is logged in the following format:

<Date>,<time>,<source ip>,<dest ip>,<protocol>,<source port>,<dest port>,<tcp flag>,<access: 0 is allow; discard is 1>, <ip header>,<ip payload>

ACLCHECK logging can be enabled or disabled from the Rule object flags attribute in iChain. There are authorized and unauthorized access logging flags.

  • When the authorized access logging flag is set, all the "allow" accesses will be logged along with the rule identification number.

  • When the unauthorized access logging flag is set, all the "deny" access attempts will also be logged. However, when a rule does not exist, the rule id will be logged as " - ".

  • If neither of these flags is set, no logging will occur for iChain.

You can acces ACLCHECK logging from the iChain GUI utility and via FTP. Using the GUI, select Monitoring > Cache Logs > Extended > Reverse: ACLCHECK and select the logs based on dates. Selecting the individual log files will bring them up in the browser and allow you to save them as local files. Alternatively, the ACLCHECK log files are stored on the LOG volume in the /etc/proxy/data/logs/reverse/extended/aclcheck/ directory. You could manually copy them to sys:\etc\proxy\ appliance\config\user and FTP them down from there using a standard FTP client.

ConsoleOne LDAP Query Tester for Dynamic ACL Rules

When defining dynamic rules for ACLCHECK, always verify that the LDAP request receives a response for the query generated. The easiest way to do this is by using the ConsoleOne LDAP browsing tool.

To enable this check, select the dynamic rules option within the ACLCHECK Rule object and go to the "Search Filter" option (see Figure 1). Here you can specify the LDAP search criteria and click on the Test button to generate the LDAP request.

Setting the Search Filter in the Advanced Query Setup window in ConsoleOne.

Authorization Troubleshooting Steps

The process of troubleshooting authorization or access control problems in iChain can be divided into three main areas:

  • Initialization problems

  • Problems when processing rules

  • Problems with LDAP communication

Proper configuration and operation of iChain needs to be verified in each of these areas separately. The following sections reference the tools listed in the previous section, as well as general iChain troubleshooting tools described in the previous AppNote referenced above.

Troubleshooting ACLCHECK Initialization Problems

Verify that the ACLCHECK module loads successfully at load time. If any errors are encountered during the load stage (either at the server console or in the PROXYCFG screen), verify the following:

  1. The ACLCHECK profile should exist on the iChain Proxy Server. This profile contains information about the LDAP server as well as the iChain ISO objects. If these attributes do not exist or contain invalid information, the "ACL: ACLCHECK Failed to Get ISO Object From Proxy Server" message will be displayed at the server console. If so, do the following:

    • From the iChain Proxy Server console, type "get authentication" and make sure that ACLCHECK is the first profile returned.

    • From the iChain Proxy Server console, type "get authentication aclcheck" and make sure you receive valid attributes as a response.

  2. A connection path should exist between the iChain Proxy server and the LDAP server. To check this, do the following:

    • From the iChain Proxy Server console, verify that a ping to the LDAP server ("ping <ldap_server_IP_address>:389") succeeds at the ICMP and TCP level.

      If the ping fails at the ICMP layer, refer to http://support.novell.com/cgi-bin/search/searchtid.cgi?/2908890.htm for information about troubleshooting IP connectivity problems.

    • Verify that a connection to TCP port 389 (LDAP) exists on the remote LDAP server. To do this, go to the iChain Proxy Server GUI and select System > Actions > Insert tab.

      If this fails, verify that the LDAP application on the LDAP server is loaded and posting a listen on TCP port 389.

      • To do this on the NetWare platform, use TCPCON and select Protocol > TCP > TCP Listeners to verify that TCP port 389 is in the "listening" state.

      • In a Windows or UNIX environment, use the "netstat -a" command to check if a TCP listener exists on TCP port 389.

  3. The LDAP Server should be set up correctly and configured to accept clear text passwords. The username and password being passed in the BIND request should be valid credentials with read, compare, and browse rights to the LDAP directory.

    • Using ConsoleOne, select the LDAP Group object and confirm that the "Allow clear text passwords" option is enabled.

    • To enable debugging on the LDAP server:

      • On a NetWare platform, use the DSTRACE=+LDAP and +TIME commands to verify the incoming requests and responses. In erroneous cases, an LDAP error code will be returned which gives useful information about the source of the problem. A list of eDirectory LDAP error codes (server and client) is available at http://developer.novell.com/ndk/doc/ldapover/index.html?ldap_enu/data/a3xfssy.html.

      • In a Windows or UNIX environment, check the LDAP application documentation to see how the LDAP Server can be set up to run in debug mode. Also refer to the LDAP server documentation for details involving error codes. (For Windows servers, a list of LDAP error codes is available at http://support.microsoft.com/support/kb/articles/q218/1/85.asp.)

    • Alternatively, do a LAN trace using a LAN analysis tool such as Sniffer and check the return codes (responses) to the requests that the iChain Proxy Server is running.

      To verify that the LDAP requests are specific to the ACLCHECK code and not another module that is loaded when the iChain Proxy server is loaded, you can modify the APPSTART.NCF file to use "load -d aclcheck" instead of "load aclcheck". This tells ACLCHECK to cause the Proxy Server to enter the debugger as it is initializing. Once the tracing session is started, simply press the <g> and <CR> keys in the debugger and ACLCHECK will continue to load.

    • Using the LSEARCH.NLM module that ships with the Novell LDAP NDK, verify that an LDAP bind request succeeds from the iChain server to the LDAP server using the same user credentials as those defined in the ACLCHEC authentication profile.

    • Make sure that at least 10 LDAP bind requests are made at this stage, as ACLCHECK is setting up a pool of LDAP handles for performance reasons. If only a single LDAP request is seen at this stage, make sure that in the APPSTART.NCF file, ACLCHECK is not being loaded with the "/c1" option! The "/cn" option defines the number of LDAP handles to be created at startup. The default of 10 is enough for most environments, but it may need to be increased under heavy loads.

  4. An LDAP search request should be sent from the iChain Proxy server to the LDAP server for all protected resource attributes of the ISO object(s) pulled out of NDS when ACLCHECK loaded in the previous step.

    By default, ACLCHECK makes a request for the following list of attributes for the ISO object (iChainProtectedResource object class) specified in the ACLCHECK authentication profile:

    • iChain protected resource access mode

    • iChain protected resource URL link

    • OLAC parameters associated with that protected resource

    If this request fails, check for the following:

    • Memory allocation errors at the server console that indicate the iChain Proxy server is running out of memory

    • LDAP return codes from the LDAP server that would possibly indicate problems with the remote directory attributes not existing

    • Large interpacket delays in LAN traces between LDAP client requests and responses. The timeout between LDAP requests is hard-coded at 10 seconds. While this is enough for almost all environments, slow WAN links or heavy LDAP server processing may require some network or LDAP server tuning.

    If the LDAP server is overloaded, it may help to increase the number of threads at the LDAP server. Use the LDAP DISPLAY CONFIG command at the LDAP server console to display the current configuration, and then use the "LDAP MAXIMUM THREADS=" command to change the default number of threads.

  5. The "ACL: ACLCHECK Initialized! Ready to Receive Requests" message should be displayed at the server console. You can verify this with a simple look at the CONSOLE.LOG file in the SYS:\ETC directory.

Troubleshooting ACLCHECK Rule Processing Problems

After ACLCHECK has successfully initialized, most of the problems occur either as a result of misconfiguring the Public access at the ISO object level, LDAP communication errors, or errors resulting from refreshing the ACLCHECK cache.

Public Access Configuration Errors. If a user tries to access a secured protected resource and is incorrectly granted access, it is likely that:

  • The user has been granted access through a Rule 0bject that the administrator is not aware of; for example, the user is a member of a group that has been granted access. Using ConsoleOne, select the user that has been incorrectly granted access and go to the iChain tab. This tab gives a list of all rules applying to that user. Look at each one closely and verify whether or not it is appropriate.

  • The cache is not stale. If a user had access to a resource and this access was revoked, the cache may still have a stale entry granting that user access until such time as the cache is refreshed. By default the ACLCHECK cache is refreshed every three hours, but this can be reduced (or increased) by loading "aclcheck /F <cache_refresh_interval_in_minutes>". Alternatively, you can trigger a refresh from the Access Control tab in the iChain GUI Config screen.

  • The ISO mode for that protected resource is set to Public in the Directory and no access control (or authentication!) is done. When this happens, use ConsoleOne to check whether the ISO's protected resource configuration is set to Public mode. If it is, no authentication or authorization will be done when users access that resource. If this is the case, make sure that the protected resource is defined as Secured so that authorization is performed.

  • The authenticated user is trying to access either of the following URLs:

    • /servlet/DocumentServlet/

    • /RegNewUser/

    For backward compatibility with iChain 1.5, the iChain 2.x Proxy server checks the incoming requests to see if the destination URL postfix is one of the above. If it is, control is not passed to ACLCHECK and the request is forwarded to the protected resource immediately. This is purely for performance reasons.

  • Check interpacket delay times between LDAP request/responses via a LAN trace. It could be that the LDAP Server is slow to respond to queries because it is overloaded. If this is the case, the LDAP client requests may be timing out. One possible solution is to increase the number of threads initialized by the LDAP server.

    • If the LDAP server is running on NetWare, use the LDAP DISPLAY CONFIG console command to view details of the LDAP server setup. You can increase the number of threads using the LDAP MAXIMUM THREADS= console command.

    • If the LDAP server is running on a UNIX platform, check the man pages for the equivalent command.

Controlled Access Configuration Errors. If a user tries to access a restricted site and is not granted access (browser will display a "403 Forbidden" message claiming that "Organizational policies prohibit access to the page") to a site that should be accessible after authenticating successfully, do the following:

  • Verify that the protected resource defined in the ISO object has a "/*" at the end of the URL host prefix (for example, http://www.novell.com/*).

  • Verify that a Rule object in the eDirectory tree exists which grants the user access to the protected resources. By default, everything is blocked unless a specific rule says otherwise.

  • Verify that the Rule objects that are being accessed have the right case. Using ConsoleOne, select the user having problems and go to the iChain tab. This tab page gives a list of all rules applying to that user. Look at each one closely and verify whether it is appropriate or not.

  • Check the ACLCHECK logs for the username/URL combination that has been denied access and confirm that both the username and URL are defined as part of a Rule object's "apply to" list.

    To provide this information, enable the ACLCHECK authorized and unauthorized logging flags via the iChain Proxy Server GUI in the Configure > Access Control tab.

  • In APPSTART.NCF, load the debug build of ACLCHECK with the "/D4" option to return information about whether or not the user is allowed and details as to why.

    If a user is allowed, the following information will be displayed at the server console, listing the Rule object that is allowing it through:

    ACL:18175: --- MATCH FOUND --- URL: http://ichain.paddy.com/iChain/index.html, User: cn=admin,o=novell, RO: dn=Admin_rule,ou=ireland,o=novell (cn=admin,o=novell)

    If a user is not allowed access because no rule allowing access has been found, the following message will appear:

    ACL:30269: ----DENIED---- URL: http://ichain.paddy.com/iChain/index.html, User: cn=guest,o=novell

    If a rule exists that would allow the user through, but the rule doesn't seem to have been found, check that:

    • The Rule object in eDirectory is configured correctly (use ConsoleOne to view the attributes of the Rule).

    • The LDAP communication is working correctly. (See the "Troubleshooting LDAP Connectivity Problems" section below for additional troubleshooting information.)

  • If query-based rules are applied, verify that the LDAP query is a valid query.

    When defining the rules in ConsoleOne, use the Test tab to confirm that the LDAP rule applies to a list of users in the eDirectory tree.

  • Check if the authentication type for that accelerator is Radius. By default, Radius servers do not return a fully distinguished name and hence the ACLCHECK algorithm will not find a match. The specific error returned on the browser will be "Status: 403 Forbidden. Description: User Name Mismatch."

    • If the radius server is not a Novell NMAS Radius server, you need to enter the following two commands at the server console:

      set authentication aclcheck ldap bindanonymous=no

      add authentication aclcheck ldap searchbase= o=novell (or appropriate container in your tree)

    • If the Radius server is a Novell NMAS Radius server, make sure that it is setup to return a FDN. (See the iChain Radius documentation for more information.)

  • Verify that the cache is not corrupt or invalid.

    Check whether the user access is only temporarily restricted. If the access problem is permanent, try to manually refresh the ACLCHEC cache by using the iChain GUI and selecting Configure > Access Control tab.

  • Verify that no exception rule exists that will block the users access to the protected resource.

Cache Refresh Problems. If problems occur after a certain time period (for example, after three hours), they could be the result of the cache refresh operations. If you suspect that this may be the issue, get the debug build of ACLCHECK that will display additional information about the refresh procedures.

  • Check for memory errors on the server console. If any of the calls to free memory fail, messages will be reported at the server console.

  • Check that the LDAP connectivity still exists to the server, as ACLCHECK will now free the current LDAP handles and re-request a new pool of LDAP handles from the LDAP server. In the TCPCON utility, selecting Protocol Information > TCP > TCP Connections should display 10 TCP connections to the LDAP server in the "established" state.

Troubleshooting LDAP Connectivity Problems

To make sure that LDAP is running without any problems, you should be aware of the following information:

  • The BIND user defined in the ACLCHECK authentication profile for LDAP queries must have rights to read (not just browse) all objects in the eDirectory tree.

  • The LDAP server must be enabled to accept clear text passwords.

  • The ACLCHECK LDAP client initializes a pool of 10 LDAP handles that will be reused on a continuous basis. Use TCPCON and select Protocol Information > TCP > TCP Connections to verity that there are 10 TCP connections to the LDAP server in the "established" state.

After the handles have been initialized, the majority of the LDAP calls made are either to get a handle from the initialized pool, or to make an LDAP search request.

To Get a Handle from the Initialized Pool of Handles. Only 10 LDAP handles are preallocated at startup. If problems exist processing information due to slow access to the LDAP server or slow performance from the LDAP server, it is possible that ACLCHECK has run out of handles. If this is the case, the following messages are likely to be displayed at the server console (resulting from calls to LDAPSDK failing):

ACL; ldap_init failed! ACL; ldap_set_option failed for LDAP_OPT_PROTOCOL_VERSION! ACL; ldap_set_option failed for LDAP_OPT_RECONNECT! ACL; ldap_set_option failed for LDAP_OPT_TIMELIMIT! ACL; ldap_simple_bind_s failed!

If this occurs due a problem at the ACLCHECK end, increase the number of LDAP handles allocated by ACLCHECK by reloading ACLCHECK with the "/c50" option. This will cause ACLCHECK to allocate 50 LDAP handles at startup to handle the high volume of LDAP requests.

If any of the above messages continues to occur, obtain a packet trace or use debug options at the LDAP Server to provide an error code that will give you more information about why the request failed.

If no LDAP request is seen in a packet trace or DSTRACE output, chances are there are no free LDAP handles. To confirm that this is an ACLCHECK problem, use the LSEARCH utility (available from the Novell LDAP NDK at http://developer.novell.com/ndk) to generate an LDAP Bind request to the LDAP server. If this works, the issue is not with the LDAP server, but with ACLCHECK. Load the debug build of ACLCHECK with the "/D4" option enabled to see what is happening internally to the LDAP handles.

To Make an LDAP Search Request. The other common use for an LDAP handle is to make the LDAP search request for information ACLCHECK needs (eDirectory Rule, User/Group/OU and Community specific objects, and corresponding attributes). If these calls fail, perform the following checks.

  • Check that eDirectory Rule objects and corresponding valid attributes exist for that user's container.

    If no specific rule exists allowing that user access to the protected resources, a check should be made to get a list of:

    • All groups for that User object

    • The User object itself

    • Security-equivalent objects (ldap_Security_Equals) for the user

    At each stage of this process, any LDAP error extracting this information will result in the following message appearing at the server console:

    ACL: ********** ccode***********: Errno

    where Errno is the error number being returned by the LDAP Server. A full list of errors may be obtained from the Novell LDAP NDK documentation.

  • Check that no memory corruption has occurred. Due to the heavy interaction with cache, a problem at this stage will likely result in the LDAP call not being made. Select the "Refresh ACLCHECK" option from within the iChain Proxy server GUI (Configure > Access Control tab), or try rebooting the iChain Proxy server.

  • Check whether a packet filtering firewall exists between the iChain Proxy server and the LDAP server. If one does exist, verify whether or not stateful filtering is enabled on it.

    When the iChain Proxy server sets up the LDAP connections to the LDAP server, some firewalls allows access through their stateful filters. However, because no keep-alive packets are exchanged between Proxy and LDAP Servers, stateful filtered enabled firewalls often kill the connection after a specified timeout (a default of 1 hour for many firewalls). If this happens, the iChain Proxy server still thinks the sessions are active, when in reality the firewall has disconnected the session.

    Here's a bit more detail as to what is happening in this scenario, which is often seen when users access a protected resource first thing in the morning. Everything works fine until sessions are idle for more than 1 hour. At this point, the stateful filtered enabled firewall kills all the LDAP sessions. When the proxy server tries to read the LDAP server for rules after this timeout has been exceeded, the connection fails. ACLCHECK has been modified to handle cases where firewalls timeout the idle sessions, so this is unlikely to be a problem.

Conclusion

Understanding the internal workings of any product will help administrators isolate and identify problems faster. This AppNote has taken a look at the authorization-related components of iChain, detailing their inner flow control and dependencies. It has described the most common support issues found, providing a list of available support tools and troubleshooting tips to help any administrator address issues discovered while working with these iChain components.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates