
Ich versuche, auf einem aktuell laufenden Computer einen virtuellen Apache-Host Red Hat Enterprise Linux release 8.5 (Ootpa)
mit Kerberos-Authentifizierung unter Verwendung des neuen GSSAPI-Moduls (Ersatz für mod_auth_kerb) auszuführen.
Ich habe auch LDAP-Direktiven konfiguriert, um meine Benutzer dank über ein LDAP zu authentifizieren mod_ldap
.
Mein krb5.conf
:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = MY.DOMAIN
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MY.DOMAIN = {
kdc = ADserver.my.domain
a_server = ADserver.my.domain
default_domain = my.domain
}
[domain_realm]
.kerberos.server = MY.DOMAIN
.my.domain = MY.DOMAIN
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
Ich habe einen Benutzer angelegt, dem ein Keytab zugewiesen ist. Mein Benutzer heißt " usersso
"
SPN-Informationen:
C:\Users\me>setspn -L usersso
Registered ServicePrincipalNames for CN=UserSso,OU=Users,DC=MY,DC=DOMAIN:
HTTP/myserver.my.domain
C:\Users\me>setspn -Q HTTP/myserver.my.domain
Checking domain DC=MY,DC=DOMAIN
CN=UserSso,OU=Users,DC=MY,DC=DOMAIN
HTTP/myserver.my.domain
Existing SPN found!
Ich habe meinen Keytab an meinen Apache-Server gesendet:
[root@myserver conf.d]# klist -ek /etc/httpd/usersso.keytab
Keytab name: FILE:/etc/httpd/usersso.keytab
KVNO Principal
---- --------------------------------------------------------------------------
4 HTTP/[email protected] (aes256-cts-hmac-sha1-96)
Keytab-Tests:
[root@myserver httpd]# kinit -V -kt /etc/httpd/usersso.keytab -p HTTP/[email protected]
Using default cache: /tmp/krb5cc_0
Using principal: HTTP/[email protected]
Using keytab: /etc/httpd/usersso.keytab
Authenticated to Kerberos v5
[root@myserver httpd]# klist -Af
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/[email protected]
Valid starting Expires Service principal
16/06/2022 13:03:23 16/06/2022 23:03:23 krbtgt/[email protected]
renew until 17/06/2022 13:03:23, Flags: FPRIA
Keytab scheint in Ordnung zu sein.
Und nun meine Virtualhost-Konfiguration:
<VirtualHost 192.168.168.168:80>
ServerName myserver.my.domain
ErrorLog /var/log/httpd/myserver.my.domain_error.log
TransferLog /var/log/httpd/myserver.my.domain_access.log
LogLevel debug
<Location />
AuthType GSSAPI
AuthName "GSSAPI Single Sign On Login"
GssapiBasicAuth On
GssapiBasicAuthMech krb5
GssapiAllowedMech krb5
GssapiCredStore keytab:/etc/httpd/usersso.keytab
GssapiLocalName On
BrowserMatch Windows gssapi-no-negotiate
AuthLDAPURL ldap://ldapserver:10400/ou=users,o=enterprise,dc=city,dc=fr?uid?sub?(objectclass=person)
AuthLDAPGroupAttribute member
AuthLDAPBindDN "cn=apache,ou=users,o=enterprise,dc=city,dc=fr"
AuthLDAPBindPassword "XXXX"
AuthzSendForbiddenOnFailure On
Require ldap-group cn=group_to_authenticate_users,ou=Groupe,ou=Profil,o=enterprise,dc=city,dc=fr
</Location>
# tag::TLSClient[]
SSLProxyEngine on
SSLProxyProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLProxyCipherSuite HIGH:!aNULL:!MD5
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
SSLProxyVerifyDepth 10
SSLOCSPEnable off
# end::TLSClient[]
ProxyPass / https://anotherserver:443/
ProxyPassReverse / https://anotherserver:443/
</VirtualHost>
Wenn ich versuche, auf meinen virtuellen Host zuzugreifen, werde ich nicht direkt weitergeleitet, anotherserver
sondern es wird ein Authentifizierungsfenster in meinem Google Chrome-Browser angezeigt (was bedeutet, dass die Kerberos-Authentifizierung nicht richtig funktioniert).
Access_log sagt:
10.10.10.10(me) - - [16/Jun/2022:11:53:21 +0200] "GET / HTTP/1.1" 401 381
Im Fehlerprotokoll steht:
[Thu Jun 16 12:49:42.867213 2022] [authz_core:debug] [pid 8154:tid 139726585538304] mod_authz_core.c(820): [client 10.10.10.10:62252] AH01626: authorization result of Require ldap-group cn=group_to_authenticate_users,ou=Groupe,ou=Profil,o=enterprise,dc=city,dc=fr: denied (no authenticated user yet)
[Thu Jun 16 12:49:42.867231 2022] [authz_core:debug] [pid 8154:tid 139726585538304] mod_authz_core.c(820): [client 10.10.10.10:62252] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Thu Jun 16 12:49:42.867256 2022] [auth_gssapi:debug] [pid 8154:tid 139726585538304] mod_auth_gssapi.c(901): [client 10.10.10.10:62252] URI: /, no main, no prev
[Thu Jun 16 12:49:42.867273 2022] [auth_gssapi:info] [pid 8154:tid 139726585538304] [client 10.10.10.10:62252] NO AUTH DATA Client did not send any authentication headers
Und schließlich, wenn ich meine Anmeldeinformationen über die Eingabeaufforderung für Anmeldeinformationen im Chrome-Browser eingebe, werde ich erfolgreich bei meiner LDAP-Gruppe authentifiziert und kann auf mein Konto zugreifen. anotherserver
Allerdings funktioniert das SSO dank Kerberos GSSAPI nicht, ich muss meine Anmeldeinformationen trotzdem manuell eingeben. :(
curL-Ergebnis: Der WWW-authenticate : Negotiate
Antwortheader ist vorhanden:
curl -k -L http://myserver.my.domain/ -v
* Trying 192.168.168.168:80...
* TCP_NODELAY set
* Connected to myserver.my.domain (192.168.168.168) port 80 (#0)
> GET / HTTP/1.1
> Host: myserver.my.domain
> User-Agent: curl/7.65.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Date: Thu, 16 Jun 2022 10:57:31 GMT
< Server: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k mod_auth_gssapi/1.6.1
< WWW-Authenticate: Negotiate
< WWW-Authenticate: Basic realm="GSSAPI Single Sign On Login"
< Content-Length: 381
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Unauthorized</title>
</head><body>
<h1>Unauthorized</h1>
<p>This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
</body></html>
* Connection #0 to host myserver.my.domain left intact
Kann mir jemand bei diesem Problem helfen?
Danke !
BEARBEITEN :
Ich habe endlich die Lösung gefunden!
- Ich habe "
BrowserMatch Windows gssapi-no-negotiate
" aus meiner Apache-Konfiguration entfernt. - Und stoppen + deaktivieren Sie den
gssproxy
Dienst, da ich immer noch nicht in der Lage bin, mit in RHEL8.6 zu arbeiten - Und vergessen Sie dann nicht, es
Environment=GSS_USE_PROXY
auf 0 zu ändern, um"gss_localname() input error"
Apache-Fehlerprotokolle zu vermeiden.