Duo Authentication Proxy ne fonctionne pas avec PANOS 8.1.7 ou plus

• Après la mise PANOS à niveau vers 8.1.7 ou plus, admin ne peut pas se connecter en firewall authentification au serveur LDAP d’authentification qui héberge un service Proxy d’authentification Duo.
• Lorsqu’un administrateur tente de se connecter à , ils obtiennent un Duo Push et quand ils frappent firewall approuver le nom d’utilisateur et la section mot de passe de l’écran de connexion serait réinitialiser le champ et dire « nom d’utilisateur invalide et mot de passe. »
• Firewall's journal du système affichera un journal indiquant que LDAP « serveur auth est en panne », quand il n’est pas.

• PAN-OS: 8,1,7 ou plus.
• Palo Alto Firewall .
• Serveur d’authentification qui héberge le service Proxy d’authentification Duo.
• Protocole: LDAP .

• Ce problème est dû à un correctif proactif qui a été ajouté dans la version 8.1.7 pour le LDAP protocole.
• Selon le LDAP protocole, une fois lié à un utilisateur spécifique (contre lequel l’authentification actuelle est contre) est fait, nous pouvons nous lier à binddn / bindpw pour les opérations LDAP futures.
• Avant la version 8.1.7, après l’authentification d’un utilisateur final (recherche de dn de l’utilisateur final et le lier avec le mot de passe de l’utilisateur final), authd ne temps se ONE lier à binddn / bindpw, mais ne vérifie pas si elle est réussie ou non.Il renvoie simplement le succès/échec de l’utilisateur final au processus de niveau supérieur.

debug: pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1203): User "test.user" is ACCEPTED (msgid = 4, LDAPp=0x13b2820)
debug: _get_AD_passwd_exp_in_days(pan_authd_shared_ldap.c:86): userAccountControl = 512 (not never expire)
debug: _get_AD_passwd_exp_in_days(pan_authd_shared_ldap.c:95): Password doesn't expire for "test.user" by maxPwdAge
debug: pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1235): Got user expire-in-days: -1 (-1 means no expiration), passwd_exp in auth profile: 7
debug: pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1279): binding back to binddn: cn=***********,ou=*********,ou=********,dc=*********,dc=***
debug: pan_authd_ldap_bind(pan_authd_shared_ldap.c:614): binding with binddn cn=***********,ou=*********,ou=********,dc=*********,dc=***
Error:  _get_ldap_result(pan_authd_shared_ldap.c:569): ldap op failed Can't contact LDAP server
Error:  pan_authd_ldap_bind(pan_authd_shared_ldap.c:629): failed to get ldap result 
Error:  pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1282): Failed to rebind, get out
debug: pan_auth_response_process(pan_auth_state_engine.c:4271): auth status: auth success

• À partir de la version 8.1.7, après l’authentification d’un utilisateur final (recherche du dn de l’utilisateur final et le lier avec le mot de passe de l’utilisateur final), authd ne jusqu’à temps se THREE lier à binddn / bindpw jusqu’à ce que le succès (dans le cas où le réseau est très instable).Même après 3 tentatives si la liaison binddn/bindpw échoue, authd retournera « besoin de se reconnecter LDAP au serveur » au niveau supérieur et considérerait la connexion pas utile.

debug: pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1232): User "test.user" is ACCEPTED (msgid = 4, LDAPp=0x1db04e0)
debug: _get_AD_passwd_exp_in_days(pan_authd_shared_ldap.c:88): userAccountControl = 512 (not never expire)
debug: _get_AD_passwd_exp_in_days(pan_authd_shared_ldap.c:136): pwdlastset: 13197988228 seconds since January 1, 1601 (UTC)
debug: _get_AD_passwd_exp_in_days(pan_authd_shared_ldap.c:155): AD pwd expires in days 37 (max 255 warning limit)
debug: pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1264): Got user expire-in-days: -1 (-1 means no expiration), passwd_exp in auth profile: 7
debug: pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1312): binding back to binddn: cn=***********,ou=*********,ou=********,dc=*********,dc=***
debug: pan_authd_ldap_bind(pan_authd_shared_ldap.c:630): binding with binddn binding back to binddn: cn=***********,ou=*********,ou=********,dc=*********,dc=***
Error:  _get_ldap_result(pan_authd_shared_ldap.c:585): ldap op failed Can't contact LDAP server
Error:  pan_authd_ldap_bind(pan_authd_shared_ldap.c:645): failed to get ldap result 
Error:  pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1315): Failed to rebind back to binddn (Try 1)
debug: pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1312): binding back to binddn: binding back to binddn: cn=***********,ou=*********,ou=********,dc=*********,dc=***
debug: pan_authd_ldap_bind(pan_authd_shared_ldap.c:630): binding with binddn binding back to binddn: cn=***********,ou=*********,ou=********,dc=*********,dc=***
Error:  pan_authd_ldap_bind(pan_authd_shared_ldap.c:639): Failed to bind ldap (Can't contact LDAP server)
Error:  pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1315): Failed to rebind back to binddn (Try 2)
debug: pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1312): binding back to binddn: binding back to binddn: cn=***********,ou=*********,ou=********,dc=*********,dc=***
debug: pan_authd_ldap_bind(pan_authd_shared_ldap.c:630): binding with binddn binding back to binddn: cn=***********,ou=*********,ou=********,dc=*********,dc=***
Error:  pan_authd_ldap_bind(pan_authd_shared_ldap.c:639): Failed to bind ldap (Can't contact LDAP server)
Error:  pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1315): Failed to rebind back to binddn (Try 3)
Error:  _generate_bind_back_to_binddn_fail_log(pan_authd_shared_ldap.c:1043): 3 tries to bind back to binddn failed: basedn: DC=*********,DC=*** ; binddn: cn=***********,
ou=*********,ou=********,dc=*********,dc=*** ; bind_timelimit 30 ; ip: 192.168.43.29 ; uri: ldap://192.168.43.29:389
Error:  _start_sync_auth(pan_auth_service_handle.c:603): LDAP auth: "Can't contact LDAP server" against 192.168.43.29:389 with 0th VOIDp=0x1db04e0
Error:  _start_sync_auth(pan_auth_service_handle.c:606): -> enter into retry interval (wait for 60 sec)
LDAP auth server 192.168.43.29 is down !!!

• Par défaut, ne DUO prend pas en charge la liaison vers binddn/bindpw après l’authentification de l’utilisateur. Cela provoque le retour de liaison à binddn / bindpw à l’échec et donc, l’authentification admin échoue.

1. Selon le LDAP protocole, la liaison vers binddn/bindpw peut être effectuée autant de fois que nécessaire au sein d’une connexion.Ainsi, un changement doit être fait à la DUO fin et cela peut être réalisé en appliquant une modification de configuration au fichier de config proxy Duo. Le client devra s’adresser à l’équipe DUO de soutien pour obtenir plus d’informations sur ces changements.

2. Utiliser pour RADIUS communiquer avec le serveur d’authentification à l’aide du service Proxy d’authentification Duo.

• Au cours LDAP de la connexion initiale entre et firewall LDAP auth serveur, authd BIND utilisera binddn / bindpw. Cette BIND opération permet de firewall s’authentifier au serveur d’annuaire et d’établir une identité d’autorisation qui sera utilisée pour une opération ultérieure.
• Lorsqu’un utilisateur fournit LDAP les informations d’identification, authd authd authentifie l’utilisateur final en recherchant le dn de l’utilisateur et en le liant au pw de l’utilisateur LDAP et en l’envoient au serveur auth. LDAP serveur auth y répondra en conséquence.
• Une fois que l’utilisateur est authentifié, authd fait la liaison vers binddn/bindpw.
• Cela permet authd de maintenir une connexion LDAP et de la réutiliser pour des millions d’authentification afin d’avoir un débit élevé.
• Si la liaison vers bindn/bindpw ne faisait pas partie du code authd, elle devra créer une nouvelle connexion pour chaque LDAP authentification, puis détruire la connexion.