LDAP bind fails, but basic ldap tools work

[viraptor]

I'm trying to connect to oktapreview LDAP gateway and get the following failure when trying to bind:

(2023-04-08  5:24:48): [be[okta]] [simple_bind_send] (0x2000): ldap simple bind sent, msgid = 2
(2023-04-08  5:24:48): [be[okta]] [sdap_op_add] (0x2000): New operation 2 timeout 1000
(2023-04-08  5:24:48): [be[okta]] [sdap_process_result] (0x2000): Trace: sh[0xaaaad60dc920], connected[1], ops[0xaaaad60e6160], ldap[0xaaaad609e810]
(2023-04-08  5:24:48): [be[okta]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
(2023-04-08  5:24:54): [be[okta]] [sdap_process_result] (0x2000): Trace: sh[0xaaaad60dc920], connected[1], ops[0xaaaad60e6160], ldap[0xaaaad609e810]
(2023-04-08  5:24:54): [be[okta]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_BIND]
(2023-04-08  5:24:54): [be[okta]] [simple_bind_done] (0x2000): Server returned control [1.3.6.1.4.1.42.2.27.8.5.1].
(2023-04-08  5:24:54): [be[okta]] [simple_bind_done] (0x0080): ldap_parse_passwordpolicy_control failed.
(2023-04-08  5:24:54): [be[okta]] [sdap_op_destructor] (0x2000): Operation 2 finished
(2023-04-08  5:24:54): [be[okta]] [sdap_cli_connect_recv] (0x0040): Unable to establish connection [1432158209]: Internal Error

I'm not sure if ldap_parse_passwordpolicy_control is actually the problem here or something else. I'm happy to try/debug some more, but with this available at log level 9, I'm not sure what to try next.

[viraptor]

I commented out checking the passwordpolicy result in sssd in this case and... the auth just worked.

[sumit-bose]

Hi,

thank you for your analysis. Looks like there is a disconnect between the Okta LDAP gateway and what OpenLDAP's libldap is expecting.

Can you try if ldapsearch is still working if you add the -e ppolicy option to the command line?

bye, Sumit

[viraptor]

Trying ldapsearch with that option results in:

Assertion failed: (buf != NULL), function ber_write, file io.c, line 108.

The verbose option doesn't give any more details.

[sumit-bose]

Hi,

thanks for checking, have you tried the debug option -d -1 ?

bye, Sumit

[viraptor]

Aha! totally missed that option.

The response parsing part is:

ldap_read: want=8, got=8
  0000:  30 2b 02 01 01 61 07 0a                            0+...a..          
tlsst_sb_read(0x6000036d8870, 37)
tlsst_session_upflags(0x6000036d8870)
ldap_read: want=37, got=37
  0000:  01 00 04 00 04 00 a0 1d  30 1b 04 19 31 2e 33 2e   ........0...1.3.  
  0010:  36 2e 31 2e 34 2e 31 2e  34 32 2e 32 2e 32 37 2e   6.1.4.1.42.2.27.  
  0020:  38 2e 35 2e 31                                     8.5.1             
ber_get_next: tag 0x30 len 43 contents:
ber_dump: buf=0x600001bc0030 ptr=0x600001bc0030 end=0x600001bc005b len=43
  0000:  02 01 01 61 07 0a 01 00  04 00 04 00 a0 1d 30 1b   ...a..........0.  
  0010:  04 19 31 2e 33 2e 36 2e  31 2e 34 2e 31 2e 34 32   ..1.3.6.1.4.1.42  
  0020:  2e 32 2e 32 37 2e 38 2e  35 2e 31                  .2.27.8.5.1       
read1msg: ld 0x600001bc8e70 msgid 1 message type bind
ber_scanf fmt ({eAA) ber:
ber_dump: buf=0x600001bc0030 ptr=0x600001bc0033 end=0x600001bc005b len=40
  0000:  61 07 0a 01 00 04 00 04  00 a0 1d 30 1b 04 19 31   a..........0...1  
  0010:  2e 33 2e 36 2e 31 2e 34  2e 31 2e 34 32 2e 32 2e   .3.6.1.4.1.42.2.  
  0020:  32 37 2e 38 2e 35 2e 31                            27.8.5.1          
read1msg: ld 0x600001bc8e70 0 new referrals
read1msg:  mark request completed, ld 0x600001bc8e70 msgid 1
request done: ld 0x600001bc8e70 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_dump: buf=0x600001bc0030 ptr=0x600001bc0033 end=0x600001bc005b len=40
  0000:  61 07 0a 01 00 04 00 04  00 a0 1d 30 1b 04 19 31   a..........0...1  
  0010:  2e 33 2e 36 2e 31 2e 34  2e 31 2e 34 32 2e 32 2e   .3.6.1.4.1.42.2.  
  0020:  32 37 2e 38 2e 35 2e 31                            27.8.5.1          
ber_scanf fmt ({a) ber:
ber_dump: buf=0x600001bc0030 ptr=0x600001bc003e end=0x600001bc005b len=29
  0000:  30 1b 04 19 31 2e 33 2e  36 2e 31 2e 34 2e 31 2e   0...1.3.6.1.4.1.  
  0010:  34 32 2e 32 2e 32 37 2e  38 2e 35 2e 31            42.2.27.8.5.1     
ber_scanf fmt (}) ber:
ber_dump: buf=0x600001bc0030 ptr=0x600001bc005b end=0x600001bc005b len=0

ldap_msgfree
Assertion failed: (buf != NULL), function ber_write, file io.c, line 108.

Running through asn1parse that gives:

    0:d=0  hl=2 l=   1 prim: INTEGER           :01
    3:d=0  hl=2 l=   7 cons: appl [ 1 ]        
    5:d=1  hl=2 l=   1 prim: ENUMERATED        :00
    8:d=1  hl=2 l=   0 prim: OCTET STRING      
   10:d=1  hl=2 l=   0 prim: OCTET STRING      
   12:d=0  hl=2 l=  29 cons: cont [ 0 ]        
   14:d=1  hl=2 l=  27 cons: SEQUENCE          
   16:d=2  hl=2 l=  25 prim: OCTET STRING      :1.3.6.1.4.1.42.2.27.8.5.1

[sumit-bose]

Hi,

thanks for the details. If I understand it correctly there is some additional data expected with the password policy control but the bindResponse from the Okta LDAP gateway only contains the "header" with the OID but no data. Unfortunately the password policy is still not a proper RFC, the latest draft can be found at https://www.ietf.org/archive/id/draft-behera-ldap-password-policy-11.txt and in section 6.2 the expected data is described.

Would it be possible to reach out to Okta with the ldapsearch debug output and ask if they can add the expected data or not send the control at all?

bye, Sumit

[viraptor]

The answer was basically "no". Specifically Okta responded:

Just to follow up on this case, I've discussed this internally with my team leads and it seems that -ppolicy is not supported at the moment, so I suggest you reach out to your customer success manager to speak in regards to this issue and to file a feature request, also I will submit a internal ticket to add this to our documentation, so we can add this limiatation.

Me trying again:

Regarding getting things to work: since the extension is not supported yet but currently is being sent in a broken state, is there any chance you could remove it from the responses until it's supported properly? That would allow us to not rely on custom patches to the ldap libraries.

Okta:

Thank you for getting back to me, as far as I know that would not be possible.

So a workaround from sssd's side would be really useful.

[sumit-bose]

Hi,

I cannot think of a workaround with the current code. I guess a new option to ignore broken password policies replies is needed.

bye, Sumit

[viraptor]

Thanks, I'll try to make a PR with the extra option.

[viraptor]

Started a draft in https://github.com/SSSD/sssd/pull/6904 - builds, but not tested yet. Raising in case the you want to tackle that in a completely different way. Otherwise, I'll mark it ready after testing.

[alexey-tikhonov]

In general, it would be much better to fix Okta, of course.

But we can also review a PR once it is available. Currently it looks stalled, so ticket will be probably closed. But if PR will be worked on and ready, then please feel free to re-open.

[viraptor]

I'll fix up that pr, definitely still on my mind. I'm just busy wrapping up other work first.

[abbra]

@viraptor any progress on this? We are considering to close this issue otherwise.

[viraptor]

I think all the feedback there is addressed. I'm yolo-ing the non-basic ldap parts which I don't really know how to reproduce though (referral/rebind) - hope the tests cover that.

[alexey-tikhonov]

Pushed PR: https://github.com/SSSD/sssd/pull/6904

• master
  • 1980e2c415666650cdb57b73055603bfd4549474 - LDAP: Allow ignoring the ppolicy extension