RE: LDAP : Who Am I extended operation

From: Denis Galiana (denis.galiana_at_nospam.nospam)
Date: 09/03/04 

Date: Fri, 3 Sep 2004 04:45:02 -0700

Hi,

After executing the following code :

---------------------------------------------------------------
        struct berval *authzid = NULL;
        int rc;
        char* returnedOID = NULL;
        ULONG iMsgID;

        rc = ldap_extended_operation(m_pLdapConnection,
                                     (PCHAR)lpszLDAPWhoAmIExtensionOID,
                                     NULL,
                                     NULL,
                                     NULL,
                                     &iMsgID);

        LDAPMessage *res;
        rc = ldap_result(m_pLdapConnection, iMsgID, 1, NULL, &res);
        if (rc != LDAP_RES_EXTENDED)
            return FMK_E_LDAP_INTERNAL;

        rc = ldap_parse_extended_result(m_pLdapConnection, res,
&returnedOID, &authzid, 0);

        rc = ldap_close_extended_op(m_pLdapConnection, iMsgID);
---------------------------------------------------------------

authzid = NULL, while it should contains the DN of the authenticated user.

Here are the OpenLDAP 'slapd' server's traces :

---------------------------------------------------------------
daemon: activity on 1 descriptors
daemon: activity on: 8r
daemon: read activity on 8
connection_get(8)
connection_get(8): got connid=11
connection_read(8): checking for input on id=11
ber_get_next
ldap_read: want=8, got=8
  0000: 30 84 00 00 00 24 02 01 0....$..
ldap_read: want=34, got=34
  0000: 03 77 84 00 00 00 1b 80 17 31 2e 33 2e 36 2e 31 .w.......1.3.6.1
  0010: 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 .4.1.4203.1.11.3
  0020: 81 00 ..
ber_get_next: tag 0x30 len 36 contents:
ber_dump: buf=0x08c51c40 ptr=0x08c51c40 end=0x08c51c64 len=36
  0000: 02 01 03 77 84 00 00 00 1b 80 17 31 2e 33 2e 36 ...w.......1.3.6
  0010: 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 .1.4.1.4203.1.11
  0020: 2e 33 81 00 .3..
ber_get_next
ldap_read: want=8 error=Resource temporarily unavailable ber_get_next on fd
8 failed errno=11 (Resource temporarily unavailable) do_extended ber_scanf
fmt ({m) ber:
ber_dump: buf=0x08c51c40 ptr=0x08c51c43 end=0x08c51c64 len=33
  0000: 77 84 00 00 00 1b 80 17 31 2e 33 2e 36 2e 31 2e w.......1.3.6.1.
  0010: 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 81 4.1.4203.1.11.3.
  0020: 00 .
ber_scanf fmt (m) ber:
ber_dump: buf=0x08c51c40 ptr=0x08c51c62 end=0x08c51c64 len=2
  0000: 00 00 ..
do_extended: oid=1.3.6.1.4.1.4203.1.11.3
send_ldap_extended: err=2 oid= len=0
send_ldap_response: msgid=3 tag=120 err=2
ber_flush: 38 bytes to sd 8
  0000: 30 24 02 01 03 78 1f 0a 01 02 04 00 04 18 6e 6f 0$...x........no
  0010: 20 72 65 71 75 65 73 74 20 64 61 74 61 20 65 78 request data ex
  0020: 70 65 63 74 65 64 pected
ldap_write: want=38, written=38
  0000: 30 24 02 01 03 78 1f 0a 01 02 04 00 04 18 6e 6f 0$...x........no
  0010: 20 72 65 71 75 65 73 74 20 64 61 74 61 20 65 78 request data ex
  0020: 70 65 63 74 65 64 pected
daemon: select: listen=6 active_threads=0 tvp=NULL
daemon: select: listen=7 active_threads=0 tvp=NULL
---------------------------------------------------------------

Here are the network packets data, as captured by ethereal on the
server's host :

(the '!' character marks the beginning of LDAP data)

---------------------------------------------------------------
Request :
---------

Message ID : 3
Message Type : Extended Request (0x17)
Mesage Length : 27

0000 00 04 76 ef 59 95 00 11 11 21 f5 a1 08 00 45 00 ..v.Y... .!....E.
0010 00 52 fd 68 40 00 80 06 d3 0f 0a 0a 09 19 0a 0a .R.h@... ........
0020 0d 01 06 27 01 85 80 8c c7 4e cc 5e 71 f6 50 18 ...'.... .N.^q.P.
0030 fa 3f 84 61 00 00!30 84 00 00 00 24 02 01 03 77 .?.a..0. ...$...w
0040 84 00 00 00 1b 80 17 31 2e 33 2e 36 2e 31 2e 34 .......1 .3.6.1.4
0050 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 81 00 .1.4203. 1.11.3..

So the concrete LDAP data is :
                  30 84 00 00 00 24 02 01 03 77
84 00 00 00 1b 80 17 31 2e 33 2e 36 2e 31 2e 34
2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 81 00

which means :
      0. ...$...w
.......1 .3.6.1.4
.1.4203. 1.11.3..

Response :
---------

Message ID : 3
Message Type : Extended Response (0x18)
Mesage Length : 31

0000 00 11 11 21 f5 a1 00 04 76 ef 59 95 08 00 45 00 ...!.... v.Y...E.
0010 00 4e ac 44 40 00 40 06 64 38 0a 0a 0d 01 0a 0a .N.D@.@. d8......
0020 09 19 01 85 06 27 cc 5e 71 f6 80 8c c7 78 50 18 .....'.^ q....xP.
0030 16 d0 2a 6e 00 00!30 24 02 01 03 78 1f 0a 01 02 ..*n..0$ ...x....
0040 04 00 04 18 6e 6f 20 72 65 71 75 65 73 74 20 64 ....no r equest d
0050 61 74 61 20 65 78 70 65 63 74 65 64 ata expe cted

So the concrete LDAP data is :
                  30 24 02 01 03 78 1f 0a 01 02
04 00 04 18 6e 6f 20 72 65 71 75 65 73 74 20 64
61 74 61 20 65 78 70 65 63 74 65 64

which means :
      0$ ...x....
....no r equest d
ata expe cted

---------------------------------------------------------------

When the extended request is done with the openldap client tool
'ldapwhoami', which does a bind, the who am i request, and an unbind,
here are OpenLDAP traces :

---------------------------------------------------------------
daemon: activity on 1 descriptors
daemon: activity on: 8r
daemon: read activity on 8
connection_get(8)
connection_get(8): got connid=1
connection_read(8): checking for input on id=1
ber_get_next
ldap_read: want=8, got=8
  0000: 30 1e 02 01 02 77 19 80 0....w..
ldap_read: want=24, got=24
  0000: 17 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 .1.3.6.1.4.1.420
  0010: 33 2e 31 2e 31 31 2e 33 3.1.11.3
ber_get_next: tag 0x30 len 30 contents:
ber_dump: buf=0x0836dfe8 ptr=0x0836dfe8 end=0x0836e006 len=30
  0000: 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31 2e 34 ...w...1.3.6.1.4
  0010: 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 .1.4203.1.11.3
ber_get_next
ldap_read: want=8 error=Resource temporarily unavailable ber_get_next on fd
8 failed errno=11 (Resource temporarily unavailable) do_extended ber_scanf
fmt ({m) ber:
ber_dump: buf=0x0836dfe8 ptr=0x0836dfeb end=0x0836e006 len=27
  0000: 77 19 80 17 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1.
  0010: 34 32 30 33 2e 31 2e 31 31 2e 33 4203.1.11.3
do_extended: oid=1.3.6.1.4.1.4203.1.11.3
send_ldap_extended: err=0 oid= len=0
send_ldap_response: msgid=2 tag=120 err=0
ber_flush: 16 bytes to sd 8
  0000: 30 0e 02 01 02 78 09 0a 01 00 04 00 04 00 8b 00 0....x..........
ldap_write: want=16, written=16
  0000: 30 0e 02 01 02 78 09 0a 01 00 04 00 04 00 8b 00 0....x..........
daemon: select: listen=6 active_threads=0 tvp=NULL
daemon: select: listen=7 active_threads=0 tvp=NULL
---------------------------------------------------------------

And eventually, here are the ethereal capture :

---------------------------------------------------------------
Request :
---------

Message ID : 2
Message Type : Extended Request (0x17)
Mesage Length : 25

0000 00 04 76 ef 59 95 00 30 05 55 7f 3a 08 00 45 00 ..v.Y..0 .U.:..E.
0010 00 54 25 95 40 00 40 06 bf f8 0a 0a 34 02 0a 0a .T%.@.@. ....4...
0020 0d 01 8d 03 01 85 d0 98 f8 a3 88 88 d1 c9 80 18 ........ ........
0030 16 d0 5b f3 00 00 01 01 08 0a a4 af dd 0f 04 c9 ..[..... ........
0040 05 af!30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 ..0....w ...1.3.6
0050 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 .1.4.1.4 203.1.11
0060 2e 33 .3

So the concrete LDAP data is :
      30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36
2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31
2e 33

which means :
  0....w ...1.3.6
.1.4.1.4 203.1.11
.3

Response :
---------

Message ID : 3
Message Type : Extended Response (0x18)
Mesage Length : 9

0000 00 30 05 55 7f 3a 00 04 76 ef 59 95 08 00 45 00 .0.U.:.. v.Y...E.
0010 00 44 d4 20 40 00 40 06 11 7d 0a 0a 0d 01 0a 0a .D. @.@. .}......
0020 34 02 01 85 8d 03 88 88 d1 c9 d0 98 f8 c3 80 18 4....... ........
0030 00 2e 55 4d 00 00 01 01 08 0a 04 c9 05 af a4 af ..UM.... ........
0040 dd 0f!30 0e 02 01 02 78 09 0a 01 00 04 00 04 00 ..0....x ........
0050 8b 00 ..

So the concrete LDAP data is :
      30 0e 02 01 02 78 09 0a 01 00 04 00 04 00
8b 00

which means :
  0....x ........
..
---------------------------------------------------------------

As you can see, the data transmitted quite differs between the two
implementations. I am not easy enough with the LDAPv3 protocol to find
out if there is a problem in the request or in the server implementation.

Best Regards,
Denis Galiana

Relevant Pages

  • Re: [PATCH][RFC] Simple tamper-proof device filesystem.
    ... If the process is in the chroot() but the daemon is not in the chroot, ... How can the daemon know whether the request is trying to manipulate nodes ... using UNIX domain socket and checks filename/attribute pair and issue ...
    (Linux-Kernel)
  • Re: [PATCH][RFC] Simple tamper-proof device filesystem.
    ... How can the daemon know whether the request is trying to manipulate nodes ... devices, so as long as the device nodes exist for all your devices, then ...
    (Linux-Kernel)
  • Re: [RFC] Re: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls
    ... daemon asking it to try and umount the select mount after which the daemon ... completion of the original ioctl expire request. ... The Generic Netlink interface won't allow this because only one concurrent ...
    (Linux-Kernel)
  • Re: creating demon programs
    ... >> Can i ask for a simple C code creating a demon? ... you might consult with the devil. ... *When a request is made, ... I've never written a daemon, but this is what I remember ...
    (comp.os.linux.questions)
  • Re[2]: nscd for freebsd
    ... If you are strict NSS, you might be able to use the ... TL> thread per request. ... TL> I think you would need to have someone work on the actual libc ... TL> code to go with the daemon, as a proof of implementation, but I ...
    (freebsd-hackers)