saslBindTokenExchange failing with invalid Credentials Error

[chapcoder]

I am trying to perform the gssapi bind using go-ldap library.
I followed below steps
1)create the keytab with ktpass command
ktpass /princ ldap/serv_acc-AD@EXAMPLE.LOCAL /mapuser serv_acc /pass Welcome1! /out C:\Users\Administrator\Documents\test.keytab /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL
2)After keytab generated, i copied in some path in the client machine and also i have configured the krb5.ini in C:\WIndows path.
3)in the code while creating the gssapi client i have provided the spn name which i have used during the keytab generation
customclient, _ := gssapi.NewClientWithKeytab("ldap/serv_acc-AD", "EXAMPLE.LOCAL", "C:\Users\MyName\Downloads\test.keytab", "C:\Windows\krb5.ini", client.DisablePAFXFAST(true))
and also i have passed the same spn in the below function
err = l.GSSAPIBind(customclient, "ldap/serv_acc-AD", "")

Now the issue is token is succesfully getting generated using the function
(https://github.com/go-ldap/ldap/blob/master/v3/bind.go#L627), but after when it calls the https://github.com/go-ldap/ldap/blob/master/v3/bind.go#L640 its failing with error "LDAP Result Code 49 "Invalid Credentials": 8009030C: LdapErr: DSID-0C09070F, comment: AcceptSecurityContext error, data 52e, v4563 ".
I am not sure what is wrong value here not able to figure out . can any one help on this?

also when i tried to check the content of keytab generation using command ktab -l -e -t -k "C:\Users\MyName\Downloads\test.keytab"

Keytab name: C:\Users\MyName\Downloads\test.keytab
KVNO Timestamp Principal

---

10 1/1/70, 2:00?AM ldap/serv_acc-AD@EXAMPLE.LOCAL (18:AES256 CTS mode with HMAC SHA1-96)

[peschu123]

I don't know if my problem is related, but I also get an Error with Invalid Credentials, even though my case is a bit different. I want to use the credentials of the currently logged-in users.

The error i get:
error performing GSSAPI bind: LDAP Result Code 49 "Invalid Credentials": 80090346: LdapErr: DSID-0C0906AB, comment: AcceptSecurityContext error, data 80090346, v4f7c

I use the code from #402 (only difference is that I use ldaps and port 636 instead of ldap) to connect from windows 10 to an active directory server (most probably server 2022). I also tried to create a client with gssapi.NewSSPIClientWithUserCredentials() but the result stays the same. I can't figure out whats wrong. I already checked my configuration over and over. Compared it with klist tickets and purged all existing tickets. I also checked with setspn -Q */dc01.mydomain.com that it is available.

From the same machine I can connect with tools like ldap admin (using kerberos) without any problems.
After looking through the functions I found the conn.debug() but it does't not help me a lot.

Here is the complete debug output

2024/08/24 16:17:00 flags&startTLS = 0
2024/08/24 16:17:00 1: waiting for response
2024/08/24 16:17:00 Sending message 1
2024/08/24 16:17:00 Receiving message 1
2024/08/24 16:17:00 1: got response 0xc00010f3b0
LDAP Response: (Universal, Constructed, Sequence and Sequence of) Len=105 "<nil>" 
 Message ID: (Universal, Primitive, Integer) Len=1 "1"
 Bind Response: (Application, Constructed, 0x01) Len=100 "<nil>"
  Result Code (Invalid Credentials): (Universal, Primitive, Enumerated) Len=1 "49"
  Matched DN (): (Universal, Primitive, Octet String) Len=0 ""
  Error Message: (Universal, Primitive, Octet String) Len=93 "80090346: LdapErr: DSID-0C0906AB, comment: AcceptSecurityContext error, data 80090346, v4f7c\x00"
2024/08/24 16:17:00 1: got response 0xc00010f3b0
LDAP Response: (Universal, Constructed, Sequence and Sequence of) Len=105 "<nil>"
 Message ID: (Universal, Primitive, Integer) Len=1 "1"
 Bind Response: (Application, Constructed, 0x01) Len=100 "<nil>"
  Result Code (Invalid Credentials): (Universal, Primitive, Enumerated) Len=1 "49"
  Matched DN (): (Universal, Primitive, Octet String) Len=0 ""
  Error Message: (Universal, Primitive, Octet String) Len=93 "80090346: LdapErr: DSID-0C0906AB, comment: AcceptSecurityContext error, data 80090346, v4f7c\x00"
2024/08/24 16:17:00 Finished message 1
2024/08/24 16:17:00 error performing GSSAPI bind: LDAP Result Code 49 "Invalid Credentials": 80090346: LdapErr: DSID-0C0906AB, comment: AcceptSecurityContext error, data 80090346, v4f7c

Chances are high that I do something stupid, but I would be glad for any pointers how to solve/debug this further. I mean it takes the credentials of the logged in user ... that should just work ;-)

thanks in advance

[FlipB]

This error

2024/08/24 16:17:00 error performing GSSAPI bind: LDAP Result Code 49 "Invalid Credentials": 80090346: LdapErr: DSID-0C0906AB, comment: AcceptSecurityContext error, data 80090346, v4f7c

may be an indication that TLS channel binding is required for that AD server (I'm basing this only on this post https://answers.microsoft.com/en-us/windowserver/forum/all/unable-to-connect-to-active-directory-using-java/56313281-bf37-47ef-be43-e77bf470b053).

Some background about channel binding: https://ldapwiki.com/wiki/Wiki.jsp?page=Channel%20Binding

[p0dalirius]

Hey @FlipB, @chapcoder, @peschu123,

It seems that I have the same problem as yours. I wrote a minimum working example of go-ldap Kerberos authentication and always get LDAP Result Code 49 "Invalid Credentials" with credentials that works on other protocols.

It seems there is a problem with SASL authentication in go-ldap?

If you want to play around with the code, it is in issue #536

Best regards,

[andy-igoshin]

It seems that I have the similar problem with DIGEST-MD5 SASL auth.

[stratg5]

I'm seeing this same issue. The GSSAPI logic was working until it was tested with Microsoft Server 2k25. 2k25 requires SSL/TLS when connecting to LDAP so this library will start to fail more and more as time goes on.

I'm using SSPI to obtain the current users credentials rather than using the username and password.

I've tried connecting to ldaps using port 636, and it gives an error saying credentials are invalid:

	sspiClient, err := gssapi.NewSSPIClient()
	if err != nil {
		return fmt.Errorf("error getting new gssapi client: %w", err)
	}

	l, err := ldap.DialURL("ldaps://" + hostname + "." + domain + ":636")
	if err != nil {
		sspiClient.Close()
		return fmt.Errorf("error dialing LDAP url: %w", err)
	}

	// bind using supplied GSSAPIClient implementation
	err = l.GSSAPIBind(sspiClient, "ldap/"+hostname+"."+domain, "")
	if err != nil {
		sspiClient.Close()
		l.Close()
		return fmt.Errorf("error binding to gssapi: %w", err)
	}

I've also tried connecting to ldap on 389, and then doing StartTLS on the connection, and that gives the same, error 49.

	sspiClient, err := gssapi.NewSSPIClient()
	if err != nil {
		return fmt.Errorf("error getting new gssapi client: %w", err)
	}

	l, err := ldap.DialURL("ldap://" + hostname + "." + domain + ":389")
	if err != nil {
		sspiClient.Close()
		return fmt.Errorf("error dialing LDAP url: %w", err)
	}

	err = l.StartTLS(&tls.Config{InsecureSkipVerify: true})
	if err != nil {
		sspiClient.Close()
		return fmt.Errorf("error starting TLS for LDAP: %w", err)
	}

	// bind using supplied GSSAPIClient implementation
	err = l.GSSAPIBind(sspiClient, "ldap/"+hostname+"."+domain, "")
	if err != nil {
		sspiClient.Close()
		l.Close()
		return fmt.Errorf("error binding to gssapi: %w", err)
	}

It seems like when using SSL/TLS, there is something in maybe the handshake process which is not setting the Kerberos token or credentials properly?

[stratg5]

It also looks like this PR broke the SSPI client in master: #537

SSPI client no longer implements the GSSAPIClient interface (missing the InitSecContextWithOptions function)

I've tried to fork and implement this function, but there's no way to use the APOptions in the SSPI client. It seems a similar change is needed in the SSPI client but I'm not sure where.

Tagging @p0dalirius in case they are aware of the fix for SSPI as well

[FlipB]

As I mentioned above, this may be due to the AD server enforcing TLS channel binding, which is currently not supported by go-ldap.

To check, you could ensure that channel binding is not enforced by changing the Active directory server settings.
Some mention of that here.

Alternatively you can try to get TLS channel binding to work (some comments about that here), which may be worth a shot if you are unable to change the settings on the AD server.

[stratg5]

Hey @FlipB yes the AD server is enforcing TLS. As of Windows Server 2k25, it is enforced by default so I think a lot more people are going to start having the same problem.

I did look at the fix in that PR you linked and tried to do the same, but the problem is that the SSPI client does not use the spnego.NewKRB5TokenAPREQ function, so I can't pass that option that fixed the standard client.

The SSPI client does something different with a token, and unfortunately I don't know enough about SSPI or GSSAPI to understand what it needs :/

But its the exact same issue as that person was seeing with the standard client (error 49 invalid credentials) so I'm sure a similar fix is needed somewhere, I just don't know where

[FlipB]

When you say "Windows Server 2025 is enforcing TLS", I presume you actually mean "enforcing TLS Channel Binding"?

Error 49 is very broad, it's not necessarily due to channel Binding, however if you know it's being enforced then that could be it.

I saw mentioned that Windows Server 2025 enabled SASL Sealing by default, which perhaps could cause issues (in which case it's likely error 49 as well).

[stratg5]

When you say "Windows Server 2025 is enforcing TLS", I presume you actually mean "enforcing TLS Channel Binding"?

Error 49 is very broad, it's not necessarily due to channel Binding, however if you know it's being enforced then that could be it.

I saw mentioned that Windows Server 2025 enabled SASL Sealing by default, which perhaps could cause issues (in which case it's likely error 49 as well).

Hi Flip,

My apologies but I'm not sure how to check this, if you let me know I can check! I think it's the last thing you mentioned though, this is just a standard Windows Server 2025 install, so it's likely the SASL sealing.

Looks like there is another related new issue as well: #552

[Chrizpy]

If the problem here turns out to be a missing channel binding token inside the returned kerberos token, I just thought I should mention that I have a PR open right now that includes a channel binding token when creating a new client context with kerberos.

I had an error that looked similar if not the same as yours prior to the changes in: #565