RADIUS-Authentifizierung nach dem Upgrade auf PAN OS 7.1.0 von 6.1. X

RADIUS-Authentifizierung nach dem Upgrade auf PAN OS 7.1.0 von 6.1. X

21656
Created On 09/25/18 19:49 PM - Last Modified 06/12/23 10:34 AM


Symptom


Symptome

Problem

  • RADIUS Server lässt Pakete fallen, da es so konfiguriert wurde, dass nur PAP-Authentifizierung unterstützt wird. 
  • Der folgende Befehl gibt keine Ausgabe an, sondern wartet nur auf eine Antwort vom RADIUS-Server.

PA-3020 (Active) > Test-Authentifizierungs-Authentifizierung-Profil "RADIUS-Profil" Benutzername Aserl Passwort
eingeben Passwort:

Diagnose

  • Vor PAN OS 7.0.0 war PAP der einzige Authentifizierungs Typ, der bei der Verwendung von RADIUS-Authentifizierung erkannt wurde.
  • Der RADIUS-Server wurde so konfiguriert, dass er nur auf PAP-Anfragen reagiert.
  • Bei PAN-OS 6.1. x sendet die Palo Alto Networks Firewall nur PAP-Type-Anfragen, die sich geändert haben, um CHAP erst nach dem Upgrade auszuprobieren, und die das Problem verursacht haben.


Resolution


  • Sobald ein globaler Protect-Benutzer versucht, sich mit dem Portal und dem Gateway zu verbinden, lässt der RADIUS-Server die von der Firewall gesendeten Zugriffs Anfrage-Pakete stillschweigend fallen. 

 

> Authd-Protokolle von der Firewall

=============================================================================================

 

PA-3020 (aktiv) > Schwanz folgen ja Schwanz folgen ja MP-Log authd. log


2016-04-08 12:36:31.734-0700 Debug: pan_authd_radius_create_req_payload (pan_authd_radius. c:178): Request Type (CHAP oder PAP) hat noch nicht ermittelt, authd versucht, CHAP-Anfrage an RADIUS Server zu senden 10.1.0.20 jetzt
2016-04-08 12:36:31.734-0700 Debug: pan_authd_radius_create_req_payload (pan_authd_radius. c:191): Benutzername: aserl
2016-04-08 12:36:31.734-0700 Debug: pan_make_radius_request_buf (pan_authd_radius_prot. c:404): RADIUS Request Type: CHAP

2016-04-08 12:36:35.712- 0700 Debug: cfgagent_doop_callback (pan_cfgagent. c:502): empfangene Signal zur Ausführung für Agent: authd
2016-04-08 12:36:35.713-0700 Debug: pan_authd_show_user_auth_stat_internal (pan_auth_ops. C:998): Got Last
pan_auth_cache_get_ vsys_domain_sso_id (pan_auth_cache_authprof_n_authseqprof. c:135): Prof "RADIUS profile", Vsys "vsys1" hat SSO-Hash-Tisch-ID: 0 (0 bedeutet Nein oder ungültiger keytab)

2016-04-08 12:37:02.820-0700 Debug: pan_auth_request_process (pan_auth_state_engine. c : 1647): der Versuch, sich zu authentifizieren: <profile: "radius="" profile",="" vsys:="" "vsys1",="" username="" "aserl"="">

2016-04-08 12:37:02.820-0700 Debug: _authenticate_by_localdb_or_remote_server (pan_auth_state_engine. c:1121): authentifizierender User "aserl" mit <profile: "radius="" profile",="" vsys:="" "vsys1"="">
2016-04-08 12:37:02.820-0700 Debug: pan_authd_radius_ create_req_payload (pan_authd_radius. c:178): Request Type (CHAP oder PAP) hat noch nicht ermittelt, authd versucht, CHAP-Anfrage an RADIUS Server zu senden 10.1.0.20 jetzt
2016-04-08 12:37:02.820-0700 Debug: pan_authd_radius_create_req_payload (pan_authd_ Radius. c:191): Benutzername: aserl
2016-04-08 12:37:02.820-0700 Debug: pan_make_radius_request_buf (pan_authd_radius_prot. c:404): RADIUS Request Type: CHAP

2016-04-08 12:37:33.873-0700 Debug: auth_svr_timeout_sent_request (pan_auth_ SVR. c:287): CHAP Timeout & Retry: authd ID = 298, Benutzername = aserl, Protokoll req ID = 1, retries = 1 (SVR ctxt timeout_in_sec 30, max_retries 5) (req abgelaufen 31 secs; Max Allowed 40 secs)

2016-04-08 12:37:38.873-0700 Debug: pan_auth_response_process ( pan_auth_state_engine. c:2424): au.Status: auth Timeout
2016-04-08 12:37:38.874-0700 Debug: _log_auth_respone (pan_auth_server. C:243): gesendete auth-Antwort für User ' aserl ' (exp_in_days = 0 (-1 nie; 0 innerhalb eines Tages)
2016-04-08 12:38:08.874-0700 Debug: pan_auth_response_process (pan_auth_state_engine. c:2424): auth Status: auth Timeout
2016-04-08 12:38:08.874-0700 Debug: pan_auth_response_process (pan_auth_state_engine. c:2591): auth scheiterte für User " aserl "Thru <"Radius profile",="" "vsys1"="">: Remote Server 10.1.0.20 des Server Profils" Radius "ist unten, oder im Retry-Intervall, oder Anfrage abgelaufen (abgelaufene Zeit 66 secs, Max erlaubt 40 secs)

</"Radius> </profile:></profile:>

 

> Protokolle vom RADIUS-Server:

=============================================================================================

 

2016-04-08T17:09:47.067480 Z | 0 | 5004 | 5020 | prfad | Event 2.
2016-04-08t17:09:47.067480 z | 0 | 5004 | 5020 | prfad | Sock 0x000000000000014C
2016-04-08T17:09:47.067480 z | 0 | 5004 | 5020 | pfrad | Code 1-ACCESS_REQUEST.
2016-04-08T17:09:47.067480 z | e | 5004 | 5020 | pfrad | Ungültiges ACCESS_REQUEST-Paket erhalten. Drop Packet.
2016-04-08T17:09:47.067480 Z | e | 5004 | 5020 | pfrad | Processincomingpacket gescheitert.

 

Da die Firewall keine Erfolgs-oder Challenge-Antwort für die Abfrage bekam, da der RADIUS-Server die Pakete fallen ließ und der Rückfall in die PAP-Authentifizierung nicht passierte, was das Problem verursachte .

 

Der RADIUS-Server wurde so konfiguriert, dass---Benutzer die Berechtigungen der GlobalProtect-Client-Software eingeben und einen Anruf per Handy erhalten, in dem er aufgefordert wird, # zur Bestätigung zu drücken;  Daher ist der Timeout mehr konfiguriert (30-40 Sekunden).

 

--Wenn der Sever nur so konfiguriert ist, dass er PAP-Authentifizierung verwendet, verwenden Sie den unten stehenden Befehl, um diese Art von Problemen zu beheben

 

> Authentifizierungs radius-auth-Typ PAP

 

 Dieser Befehl wird über Reboots hinweg hartnäckig sein, aber nicht über Software-Updates

 

Nach diesem Befehl wurde der Benutzer erfolgreich mit dem GP verbunden

 

Authd Logs

=====================

2016-04-08 13:39:49.991-0700 Debug: pan_authd_radius_create_req_payload (pan_authd_radius. c:191): Benutzername: aserl
2016-04-08 13:40:09.986-0700 Debug: pan_make_radius_request_buf (pan_authd_radius_prot. c:412): RADIUS Request Type: PAP
2016-04-08 13:40:13.151-0700 Debug: pan_authd_radius_parse_resp_payload (pan_authd_radius. c:241): resp_code = RAD_ACCESS_ACCEPT
2016-04-08 13:40:13.151-0700 Debug: pan_auth_service_recv_response (pan_auth_service_handle. c:1202 ): Bekam Antwort für Nutzer: "aserl"
2016-04-08 13:40:13.151-0700 Debug: pan_auth_response_process (pan_auth_state_engine. c:2424): auth-Status: auth -Erfolg

 

 

 

Danke.



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClePCAS&lang=de&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language