0 Replies Latest reply on Nov 22, 2019 8:58 AM by Daniel Straub

    Elytron: PartialResultException by referral=ignore

    Daniel Straub Newbie

      We migrated some security stuff from classic login modules to elytron (JBoss EAP 7.2.2), using an active directory with referrals.

      Our configuration looks like this:

       

      <ldap-realm name="ApplicationLdapRealm" dir-context="ldap" direct-verification="true">

        <identity-mapping rdn-identifier="sAMAccountName" use-recursive-search="true" search-base-dn="DC=xxx,DC=xxxx,DC=xxxxx">

          <attribute-mapping>

            <attribute from="sAMAccountName" to="Roles"/>

          </attribute-mapping>

         </identity-mapping>

      </ldap-realm>

       

      <dir-context name="ldap" url="ldaps://xxxxx:636" principal="CN=xxxxx,OU=xxxx,OU=xxxx,DC=xxxx,DC=xxx" referral-mode="IGNORE">

        <credential-reference store="credentials" alias="ldap"/>

      </dir-context>

       

      If an login with an unknown sAMAccountName occurs, the result is now an HTTP 500 Internal Server Error instead 401 (the behaviour in JB7.0/legacy security).

      In general, it's a little bit hard to figure out what the reason is - the elytron subsystem is very silent ... It would be fine if errors/exception during logins are logged.
      So we had to switch the log level of org.wildfly.security to TRACE :

       

      DEBUG [org.wildfly.security] (default task-26) Creating [class javax.naming.directory.InitialDirContext] with environment:

      DEBUG [org.wildfly.security] (default task-26)     Property [java.naming.security.credentials] with value [******]

      DEBUG [org.wildfly.security] (default task-26)     Property [java.naming.security.authentication] with value [simple]

      DEBUG [org.wildfly.security] (default task-26)     Property [java.naming.provider.url] with value [ldaps://xxxxx:636]

      DEBUG [org.wildfly.security] (default task-26)     Property [com.sun.jndi.ldap.read.timeout] with value [60000]

      DEBUG [org.wildfly.security] (default task-26)     Property [com.sun.jndi.ldap.connect.pool] with value [false]

      DEBUG [org.wildfly.security] (default task-26)     Property [com.sun.jndi.ldap.connect.timeout] with value [5000]

      DEBUG [org.wildfly.security] (default task-26)     Property [java.naming.security.principal] with value [CN=xxxxxx]

      DEBUG [org.wildfly.security] (default task-26)    Property [java.naming.referral] with value [ignore]

      DEBUG [org.wildfly.security] (default task-26)     Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory]

      DEBUG [org.wildfly.security] (default task-26) [javax.naming.ldap.InitialLdapContext@17bfaf25] successfully created. Connection established to LDAP server.

      DEBUG [org.wildfly.security] (default task-26) Trying to create identity for principal [xxxxx].

      DEBUG [org.wildfly.security] (default task-26) Executing search [(sAMAccountName={0})] in context [DC=ms,DC=bgnet,DC=de] with arguments [xxxxxxx]. Returning attributes are [null]. Binary attributes are [null].

      DEBUG [org.wildfly.security] (default task-26) Context [javax.naming.ldap.InitialLdapContext@17bfaf25] was closed. Connection closed or just returned to the pool.

      TRACE [org.wildfly.security] (default task-26) BASIC: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.http.HttpAuthenticationException: java.io.IOException: java.lang.RuntimeException: ELY01084: Error while consuming results from search. SearchDn [DC=ms,DC=bgnet,DC=de], Filter [(sAMAccountName={0})], Filter Args [[S48ST00AWSx]].

      ...

      Caused by: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'DC=xxx,DC=xxx,DC=xxx'

      TRACE [org.wildfly.security.http] (default task-26) Authentication failed.: org.wildfly.security.http.HttpAuthenticationException: ELY06016: HTTP authentication failed validating request, no mechanisms remain to continue authentication.

       

      Our expectation is to receive an HTTP 401, not an HTTP 500 (without any informations in the logs).

       

      If we switch to "referral-mode="FOLLOW", the result is an correct 401 - but in this case the search takes to long so that isn't an option.

       

      So, what we like to have :

      - in elytron the same behaviour as in the old picketbox

      - errors should be logged with the appropriate log level