3 Replies Latest reply: Mar 13, 2014 4:07 AM by User13344206-Oracle RSS

    authn and authz issues with OUD

    fchagnon

      I have an application that supports LDAP as a means of authentication and authorization. I would like to have it use our OUD-based identity store. This is not an open system; I have no control over the client's behaviour, so any tweaking I do to make it work must be done on the server side.

       

      Authentication Issue:

      If I just enter a username "firstname.lastname" (as is our convention), the application sends this string verbatim to OUD and fails.

      [11/Mar/2014:14:49:34 -0400] CONNECT conn=67 from=xxx.xxx.xxx.xxx:44715 to=xxx.xxx.xxx.xxx:1636 protocol=LDAPS

      [11/Mar/2014:14:49:34 -0400] BIND REQ conn=67 op=0 msgID=1 type=SIMPLE dn="firstname.lastname"

      [11/Mar/2014:14:49:34 -0400] BIND RES conn=67 op=0 msgID=1 result=1 message="The provided value "firstname.lastname" could not be parsed as a valid distinguished name because it contained an RDN containing an empty attribute name" etime=23

      This is predictable as the application is not smart enough to expand this username to something smart like "uid=firstname.lastname,ou=People,dc=example,dc=com". However, if I authenticate with this full qualified DN, authentication succeeds.

       

      I don't don't expect my users to remember this ugly DN string. Is there anyway I can tweak the OUD side to accept these types of shortened aliases? Or am I verging on OVD territory here?

       

      Authorization Issue:

      The application is capable of mapping it's internal authorization levels to LDAP groups. The problem here is that it uses searches for memberOf (AD) or groupMembership (Novell) attributes in order to ascertain group membership, rather than the conventional memberUid or ismemberOf.

      [11/Mar/2014:14:49:59 -0400] SEARCH REQ conn=71 op=1 msgID=2 base="uid=firstname.lastname,ou=People,dc=example,dc=com" scope=baseObject filter="(objectclass=user)" attrs="memberOf,groupMembership"

      [11/Mar/2014:14:49:59 -0400] SEARCH RES conn=71 op=1 msgID=2 result=0 nentries=0 etime=0

      The result of course is that group membership is not properly found, and thus authorizations are not assigned.

       

      I understand that I can create a virtual attribute, based on ismemberof, but called memberof, which should be able to add support for this query but I cannot find a working recipe to properly add this functionality.

      Has anyone done anything like this before?

       

      Running OUD 11.1.2.1.0

       

      Thanks.

      Fred

        • 1. Re: authn and authz issues with OUD
          User13344206-Oracle

          About Authentication issue :

          OUD has the ability to use Identity mappers that will search the user for you in the local databases in case when it is not a DN

          The default configuration happens to use an exact match identity mapper based on attribute uid which seems to be exactly what you are needing,

          however the default OUD configuration  does not allow simple bind with non DN but only allows this for SASL BIND.

          So what you need to do is simply go in the OUD global configuration and change the property called  non-dn-simple-bind-allowed to value true

          and BIND should start working with BIND ID like "firstname.lastname"

           

          About the Authorization issue :

          I am not sure about this one but the problem you are experiencing could simply be caused by the order in which virtual attributes are computed (ismember itself is a virtual attribute)

          and it is possible that changing the name of your new attribute to something that comes earlier or later than ismemberof in the alphabetic order could fix the problem

          (unfortunately there is no way to define a formal order for  the virtual attribute processing)

           

          Gilles

          • 2. Re: authn and authz issues with OUD
            fchagnon

            Excellent. Changing that setting looks to be a step in the right direction. Authentication works smoothly now using the shortened username, but now the authorization problem is different. Where before I could do a valid query for the uid- string, now OUD is throwing an error when trying to search the group membership of an invalid RDN.

            [12/Mar/2014:12:46:49 -0400] CONNECT conn=187 from=xxx.xxx.xxx.xxx:3356 to=xxx.xxx.xxx.xxx:1636 protocol=LDAPS

            [12/Mar/2014:12:46:50 -0400] BIND REQ conn=187 op=0 msgID=1 type=SIMPLE dn="firstname.lastname"

            [12/Mar/2014:12:46:50 -0400] BIND RES conn=187 op=0 msgID=1 result=0 authDN="uid=firstname.lastname,ou=People,dc=example,dc=com" etime=6

            [12/Mar/2014:12:46:50 -0400] SEARCH REQ conn=187 op=1 msgID=2 base="firstname.lastname" scope=baseObject filter="(objectclass=user)" attrs="memberOf,groupMembership"

            [12/Mar/2014:12:46:50 -0400] SEARCH RES conn=187 op=1 msgID=2 result=34 message="The provided value "firstname.lastname" could not be parsed as a valid distinguished name because it contained an RDN containing an empty attribute name" nentries=0 etime=1

            [12/Mar/2014:12:46:50 -0400] SEARCH REQ conn=187 op=2 msgID=3 base="dc=example,dc=com" scope=wholeSubtree filter="(&(objectclass=user)(|(samAccountName=firstname.lastname)(displayName=firstname.lastname)(userPrincipalName=firstname.lastname)))" attrs="dn"

            [12/Mar/2014:12:46:50 -0400] SEARCH RES conn=187 op=2 msgID=3 result=0 nentries=0 etime=0

            [12/Mar/2014:12:46:50 -0400] UNBIND REQ conn=187 op=3 msgID=4

            [12/Mar/2014:12:46:50 -0400] DISCONNECT conn=187 reason="Client Disconnect"

            Is there more work to be done in the Identity Mappers configuration to get this follow-up query to work?

             

            As for virtual attributes, I have not yet registered "memberOf" as a virtual attribute and tested it. I was asking if doing so was a recommended course of action for this type of scenario. I will give it a shot and see what happens.

            • 3. Re: authn and authz issues with OUD
              User13344206-Oracle

              Unfortunately, the Identity Mappers are dedicated to the BIND operation. They do not allow to change the base DN of search operation.