[RISOLTO] Errore Kerberos 405

Marceld · 22 marzo 2023 - 13:54

Ciao a tutti,

Da oltre un anno utilizziamo il nostro server WAPT Enterprise (aggiornato) in produzione su un server Ubuntu (anch'esso aggiornato).

Per i dettagli della versione:

Versione WAPT 2.3.0.13516

Ubuntu 22.04.2 LTS

Volevamo abbandonare NTLM nel nostro dominio e utilizzare solo Kerberos.

Abbiamo quindi iniziato a configurare WAPT con Kerberos.

- Tutte le configurazioni soddisfano i prerequisiti (sezione di installazione Debian)
- Abbiamo seguito la documentazione sul "rafforzamento della sicurezza del tuo server WAPT" (ad eccezione della parte Firewall che implementeremo dopo Kerberos).

L'intero processo di "configurazione e post-configurazione di Kerberos" si è svolto senza intoppi.

Tuttavia, ora è impossibile connettersi dal centro software WAPT.

Se seguo la documentazione, ottengo:
- use_kerberos=True è correttamente abilitato sia sul lato client che su quello server
- Il Keytab è buono e conforme a quanto presentato nella documentazione
- Il comando "kinit -k -t /etc/nginx/http-krb5.keytab srvwapt\$@AD.TRANQUIL.IT" genera effettivamente un ticket per il server (klist)
- Su un PC client, utilizzando la console di sistema e il comando "wapt-get register", riesco a registrare correttamente il dispositivo:

C:\windows\system32>wapt-get register
Utilizzo del file di configurazione: C:\Program Files (x86)\wapt\wapt-get.ini
Registrazione dell'host sul server: https://srvwapt.toto.local
Host correttamente registrato sul server https://srvwapt.toto.local.

Se eseguo un test utilizzando il comando Curl, ottengo un errore: http/1.1 405 METODO NON CONSENTITO:

> GET /add_host_kerberos HTTP/1.1
> Host: frscmwapt.scmlemans.com
> Authorization: Negotiate CLE_EFFACE
> User-Agent: curl/7.81.0
> Accept: */*
>
* TLSv1.2 (IN), intestazione TLS, dati supplementari (23):
* Contrassegna il bundle come non supportante multiuso
< HTTP/1.1 405 METHOD NOT ALLOWED
< Server: nginx
< Date: Wed, 22 Mar 2023 12:33:32 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 178
< Connection: keep-alive
< WWW-Authenticate: Negotiate KEY_ERAS
< WWW-Authenticate: Basic realm=""
< Allow: OPTIONS, POST, HEAD
< Strict-Transport-Security: max-age=63072000
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>405 Method Not Allowed</title>
<h1>Method Not Allowed</h1>
<p>The method is not allowed for the requested URL.</p>
* La connessione n. 0 all'host srvwapt.toto.local è rimasta intatta

Se faccio il test su Firefox come menzionato una o due volte sul forum, ottengo lo stesso risultato (405 METODO NON CONSENTITO)

Se richiedo un ticket dal PC di un utente, viene restituito quanto segue:

C:\windows\system32>klist get https://srvwapt.toto.local

LogonId è 0:0x3e7
Errore durante la chiamata all'API LsaCallAuthenticationPackage (substatus GetTicket): 0x6fb

klist non riuscito con 0xc000018b/-1073741429: Il database SAM del server Windows non dispone di un account computer per la relazione di fiducia con questa workstation.

Infine, nessun utente può più utilizzare il centro software (il che per me ha senso, visto che la richiesta Kerberos non è riuscita)
Tuttavia, la console di amministrazione continua a funzionare (il che ha senso poiché non utilizza Kerberos).

Mi scuso per il "muro di testo" e grazie per aver letto.

22 marzo 2023 - 14:41

Se vedi il messaggio "Metodo non consentito", allora è tutto a posto

Puoi anche provare a utilizzare il seguente URL nel tuo browser:

Codice: Seleziona tutto

https://srvwapt.mydomain.lan/api/v3/login_kerberos

Affinché Kerberos funzioni sul lato self-service, è necessario aggiungere quanto segue al file wapt-get.ini dei propri agenti:

Codice: Seleziona tutto

[global]
use_kerberos=1
service_auth_type=waptserver-ldap

e sul lato server Wapt, configurare LDAP in /opt/wapt/conf/waptserver.ini

Mettere :

Codice: Seleziona tutto

[options]
ldap_auth_server = srvads.mydomain.lan
ldap_auth_base_dn = DC=mydomain,DC=lan
ldap_auth_ssl_enabled = False
verify_cert_ldap = False
ldap_account_service_login = wapt-ldap@mydomain.lan
ldap_account_service_password = password

quindi riavviare il server wapt:

Codice: Seleziona tutto

systemctl restart waptserver

Marceld · 22 marzo 2023 - 14:59

Ciao Sfontenau,

COSÌ :

https://srvwapt.miodominio.lan/api/v3/login_kerberos

Inizialmente indica "Autenticazione OK":

: ok.JPG (27,79 KB) Visualizzato 7562 volte

[globale]
use_kerberos=1
service_auth_type=waptserver-ldap

Quindi è proprio questo il punto che volevo sollevare. Ho esaminato attentamente la documentazione e il forum, e a volte dice "1" e altre volte "Vero". Sono entrambe accettabili?

[opzioni]
ldap_auth_server = srvads.mydomain.lan
ldap_auth_base_dn = DC=mydomain,DC=lan
ldap_auth_ssl_enabled = False
verify_cert_ldap = False
ldap_account_service_login = wapt-ldap@mydomain.lan
ldap_account_service_password = password

Avevo già provato ad aggiungerli (li ho rimossi dai commenti ma il problema non è cambiato)
È sufficiente un account utente standard o sono richiesti privilegi specifici?

Grazie per il tuo tempo.

22 marzo 2023 - 16:48

Marceld ha scritto: ↑22 marzo 2023 - 14:59

Quindi è proprio questo il punto che volevo sollevare. Ho esaminato attentamente la documentazione e il forum, e a volte dice "1" e altre volte "Vero". Sono entrambe accettabili?

Sì, assolutamente, 1 = Vero quindi puoi mettere quello che vuoi

È sufficiente un account utente standard o sono richiesti privilegi specifici?

Sono necessari i diritti per leggere l'attributo memberof dei record utente (è possibile testarlo con il piccolo software ldapadmin)

Marceld · 22 marzo 2023 - 18:42

Grazie per lo strumento.

L'account utente creato può effettivamente leggere l'attributo "Membro di".

Se i test Kerberos hanno esito positivo ma l'SSO del Software Center non funziona, quale potrebbe essere la causa?

23 marzo 2023 - 10:17

L'unica cosa che non abbiamo verificato è il pacchetto di regole self-service.

È installato un pacchetto di regole self-service?

Ricevi un messaggio di errore quando lo apri?

Marceld · 23 marzo 2023 - 12:05

Salve,

sì, esiste un pacchetto self-service per gli utenti.

Ha funzionato correttamente con l'autenticazione NTLM.

Visualizza semplicemente "password o nome utente errati" sia che io inserisca una password o meno.

Inoltre, non riesco ad aprirlo con un account che ha i diritti di amministratore locale.

Buona giornata.

23 marzo 2023 - 12:19

Se il tuo agente è configurato correttamente in questo modo, non dovrebbe richiedere una password:

Codice: Seleziona tutto

[global]
use_kerberos=1
service_auth_type=waptserver-ldap

Poi :

Codice: Seleziona tutto

net stop waptservice
net start waptservice

Marceld · 23 marzo 2023 - 15:23

Se il tuo agente è configurato correttamente in questo modo, non dovrebbe richiedere una password:

Ah ok, in un altro argomento hai specificato che l'ID e la password erano sempre necessari se avessimo dovuto passare all'amministrazione.

use_kerberos=1
service_auth_type=waptserver-ldap

Posso confermare che questa è effettivamente la configurazione che ho sul mio client di prova.

Non vedo nulla nei log lato client riguardo a un possibile errore. C'è un posto specifico dove posso trovare i log relativi al tentativo di connessione?

Marceld · 23 marzo 2023 - 17:10

Per tua informazione, e dopo aver parlato con l'assistenza telefonica:

È stato un errore da parte mia:

Ho modificato la seguente riga:

service_auth_type=waptserver-ldap

di :

service_auth_type=mywaptserver.toto.local

È stato un errore da parte mia; quella frase non avrebbe dovuto essere modificata.

Grazie ancora per la tua reattività!

Finalmente potremo sbarazzarci di NTLM