cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
120
Views
0
Helpful
3
Replies

DUO reporst SASL (GSSAPI) issues during authentication

In our setupm we would like to integrage Palo Alto Globalprotect with dou MFA using local LDAP server for authentication. We would like to use plain text passwords for testing purposes, but it seems, duo executes SASL(GSSAPI) authetication method, even though this is disabled.

Config file(hostnames and other personal data are correct in original file):

[ad_client]
host=x.x.x.x
service_account_username=admin
service_account_password=xxx
search_dn=cn=Users,dc=xxx,dc=xxx
port=389
use_gssapi=false
security=plain
timeout=60

[ldap_server_auto]
client=ad_client
ikey=xxx
skey=xxx
api_host=api-xxx
use_gssapi=false

The config above is working without duo, I mean if I create an LDAP profile in Palo firewall pointing directly to LDAP server, the authentication is successfull.

If I create an LDAP profile pointing to duo proxy server, I get the following error:

2024-10-01T15:07:02.194352+0200 [duoauthproxy.lib.log#info] Failed to look up username for 2FA: "other: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (Key table file '/etc/krb5.keytab' not found)"

How to avoid this? Why SASL is in scope if I disabled?

Thanky you for the help in advance!

 

 

 

1 Accepted Solution

Accepted Solutions

DuoKristina
Cisco Employee
Cisco Employee

I think you meant to use "auth_type=plain" in the ad_client section, not "security=plain"? Also "use_gssapi" isn't a valid option for authproxy.cfg.

Read about the auth_type option and its additional requirements here: https://duo.com/docs/authproxy-reference#ad_client

 

 

 

Duo, not DUO.

View solution in original post

3 Replies 3

DuoKristina
Cisco Employee
Cisco Employee

I think you meant to use "auth_type=plain" in the ad_client section, not "security=plain"? Also "use_gssapi" isn't a valid option for authproxy.cfg.

Read about the auth_type option and its additional requirements here: https://duo.com/docs/authproxy-reference#ad_client

 

 

 

Duo, not DUO.

Thank you for the correction, I was working with an incorrect sample file...Even though this issue solved, I have a new one. User credentials are asked with wrong DN somehow, so the LDAP server refuses the request. My curren Duo config file is the following:

[main]
debug=true

[ad_client]
host=x.x.x.x
service_account_username=x
service_account_password=x
search_dn=dc=xxx,dc=xx
port=389
auth_type=plain
timeout=60

[ldap_server_auto]
client=ad_client
ikey=x
skey=x
api_host=api-x

Log from Dou Proxy:

2024-10-03T09:47:23.868123+0200 [Uninitialized] C->S LDAPMessage(id=8, value=LDAPBindRequest(version=3, dn='<ROOT>', auth='****', sasl=False), controls=None)
2024-10-03T09:47:23.868819+0200 [_ADServiceClientProtocol,client] C<-S LDAPMessage(id=8, value=LDAPBindResponse(resultCode=34, errorMessage=b'invalid DN'), controls=None)
2024-10-03T09:47:23.869426+0200 [duoauthproxy.lib.log#info] Failed to look up username for 2FA: 'invalidDNSyntax: invalid DN'

Logs from openLDAP:

2024-10-03T09:47:23.842694+02:00 auth-server slapd[1284]: conn=1054 fd=15 ACCEPT from IP=10.10.40.91:59072 (IP=0.0.0.0:389)
2024-10-03T09:47:23.843158+02:00 auth-server slapd[1284]: conn=1054 op=0 do_bind: invalid dn (<ROOT>)
2024-10-03T09:47:23.843217+02:00 auth-server slapd[1284]: conn=1054 op=0 RESULT tag=97 err=34 qtime=0.000011 etime=0.000049 text=invalid DN

Palo Alto config:

mihalykukucska81_0-1727942506422.png

Palo Alto Globalprotect user can authenticate via this LDAP server without Duo, by integrating Duo to setup I ran into this issue. I cant find that part of the config, which can cause this. Can you give me a hint?

 

Found the root-cause in documentation. Thx

Quick Links