Resultados de la búsqueda :
×Kerberos es un protocolo de autenticación basado en criptografía que protege el acceso a las aplicaciones. Este protocolo está diseñado para proporcionar autenticación segura a través de una red insegura. La idea clave detrás de Kerberos es autenticar a los usuarios y al mismo tiempo evitar que se envíen contraseñas a través de Internet.
Kerberos: Kerberos es un protocolo de autenticación que admite el concepto de inicio de sesión único (SSO). En el caso de HTTP, el soporte para Kerberos generalmente se proporciona mediante el término mecanismo de autenticación "SPNEGO".
Reino Kerberos: Un dominio administrativo para la autenticación se indica con el término dominio. Su objetivo es definir las restricciones sobre cuándo un servidor de autenticación puede autenticar a un usuario, host o servicio. Esto no implica que un usuario y un servicio deban ser miembros del mismo dominio para que se produzca la autenticación: si los dos objetos están conectados a través de una conexión de confianza a pesar de pertenecer a dominios diferentes, la autenticación aún puede ocurrir.
Director: En un sistema Kerberos, un principal de Kerberos representa una identidad distinta a la que Kerberos puede emitir tickets para acceder a servicios compatibles con Kerberos. El separador "/" se utiliza para separar los distintos componentes que componen los nombres principales. El carácter "@" se puede utilizar para identificar un reino como elemento final del nombre. Si no se especifica ningún dominio, se supone que Principal pertenece al dominio predeterminado establecido en el archivo krb5.conf.
Clientes/Usuarios: un proceso que accede a un servicio en nombre de un usuario. Puede haber varios clientes o usuarios dentro de un dominio.
Servicio: Algo a lo que el usuario quiere acceder.
SSO: El inicio de sesión único es un procedimiento que permite a un usuario iniciar sesión solo una vez y acceder a numerosos servicios después de completar la autenticación del usuario. Después de iniciar sesión en un servicio principal, esto implica la autenticación en cada servicio al que el usuario haya otorgado autorización. SSO tiene una serie de ventajas, una de las cuales es evitar el tedioso proceso de validar repetidamente la identidad mediante contraseñas u otros sistemas de autenticación.
GSSAPI: Los programas pueden acceder a los servicios de seguridad a través de la Interfaz de programa de aplicación de servicio de seguridad genérico (GSSAPI), que es una interfaz de programación de aplicaciones (API). Un estándar del IETF es GSSAPI. No ofrece ninguna seguridad por sí solo. En cambio, las implementaciones GSSAPI las ofrecen los proveedores de servicios de seguridad. El intercambio de mensajes opacos (tokens), que ocultan los detalles de implementación a la aplicación de nivel superior, es la característica distintiva de las aplicaciones GSSAPI.
ESPNEGO: El software cliente-servidor utiliza el mecanismo de negociación GSSAPI simple y protegido, frecuentemente llamado "spen-go", para negociar la selección de tecnología de seguridad. Cuando una aplicación cliente tiene que iniciar sesión en un servidor remoto pero ninguno de los extremos está seguro de qué protocolos de autenticación admite el otro, se emplea SPNEGO. El pseudomecanismo utiliza un protocolo para identificar los mecanismos GSSAPI comunes disponibles, elige uno y luego asigna todas las acciones de seguridad posteriores a ese mecanismo elegido.
KDC: Un Centro de Distribución de Claves es un servicio de red que suministra tickets y claves de sesiones temporales; o una instancia de ese servicio o el host en el que se ejecuta. El KDC atiende tanto las solicitudes de boletos iniciales como las de concesión de boletos. La parte inicial del ticket a veces se denomina servidor (o servicio) de autenticación. La parte del ticket que otorga el ticket a veces se denomina servidor (o servicio) que otorga el ticket.
El acceso de un cliente a un recurso en un dominio de Active Directory se puede autenticar utilizando el protocolo de autenticación de desafío-respuesta conocido como Windows NT LAN Manager (NTLM). Cuando un cliente solicita acceso a un servicio relacionado con el dominio, el servicio envía un desafío al cliente, indicándole que use su token de autenticación para realizar una operación matemática y luego proporciona el resultado al servicio. El resultado puede ser verificado por el servicio o por el controlador de dominio (DC). El servicio otorga acceso al cliente si el DC o el servicio verifica que la respuesta del cliente es precisa.
Debido a que permite al usuario ingresar el factor de autenticación subyacente solo una vez, durante el inicio de sesión, NTLM es una especie de inicio de sesión único (SSO).
ktpass -princ HTTP/<Server Host Name>@EXAMPLE.COM -mapuser <username@EXAMPLE.COM>
-pass password -ptype KRB5_NT_PRINCIPAL -out <PATH>\spn.keytabNota: Asegurar EJEMPLO.COM debe estar en mayúsculas. Si el usuario con SPN ya existe, utilícelo en lugar de crear uno nuevo. El principio de Kerberos distingue entre mayúsculas y minúsculas. Verifique las diferencias en la escritura en mayúsculas y minúsculas antes de ejecutar el comando keytab.
| Nombre del host del servidor: | Es el nombre de host del sitio alojado en el servidor. |
| EJEMPLO.COM: | Es el nombre de dominio de Active Directory. |
| Nombre de usuario: | Es una cuenta de servicio en Active Directory. |
| Contraseña: | Es la contraseña de la cuenta de servicio utilizada anteriormente. |
| ruta de acceso: | Ruta a una ubicación local que almacenará el archivo keytab. (C:\Temp\spn.keytab) |
Nota: El comando anterior crea un archivo de tabla de claves. Debe colocarse en el servidor del cliente donde está alojado su sitio de WordPress. El usuario que ejecuta Apache debería tener acceso completo a este archivo. El usuario debe tener permiso para acceder al archivo keytab.
chmod 644 etc/apache2/spn.keytab
sudo apt-get install krb5-user
Nota: En las versiones más recientes de Ubuntu/Debian, el mod_auth_kerb ha sido obsoleto y reemplazado por el mod_auth_gssapi.
sudo apt-get install libapache2-mod-auth-kerba2enmod auth_kerbsudo apt-get -y install libapache2-mod-auth-gssapi
[libdefaults]
default_realm = EXAMPLE.COM
# ...
# ...
[realms]
EXAMPLE.COM = {
kdc = <DNS entries pointing to your primary domain controller>: Port
admin_server = <DNS entries pointing to your primary domain controller>: Port
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Nota: Vuelva a colocar la ANUNCIO CONTROLADOR DE DOMINIO IP/DNS con su dirección IP/DNS. Asegurar EJEMPLO.COM debe estar en mayúsculas.
Vuelva a colocar la EJEMPLO.COM con el nombre de dominio de Active Directory.
Y asegúrese de que se pueda acceder al puerto 88 en el controlador de dominio AD desde este servidor.
Nota: Agregue la siguiente sección en el directorio según el módulo de Apache utilizado. P.ej: "mod_auth_kerb" or "mod_auth_gssapi".
<Directory "/placeholder">
AuthType Kerberos
KrbAuthRealms EXAMPLE.COM
KrbServiceName HTTP/<Server Host Name>
Krb5Keytab <PATH TO KEYTAB>
KrbMethodNegotiate on
KrbMethodK5Passwd on
require valid-user
</Directory>
<IfModule !mod_auth_gssapi.c>
LoadModule auth_gssapi_module /usr/lib64/httpd/modules/mod_auth_gssapi.so
</IfModule>
<Directory "/placeholder">
AuthType GSSAPI
AuthName "Kerberos auth"
GssapiAllowedMech krb5
GssapiBasicAuth On
GssapiCredStore keytab:<PATH TO KEYTAB>
GssapiLocalName On
BrowserMatch Windows gssapi-no-negotiate
Require valid-user
</Directory>
Nota: Asegurar EJEMPLO.COM debe estar en mayúsculas.
Los siguientes son los componentes de la configuración anterior:
| EJEMPLO.COM: | Este es el dominio de Active Directory configurado en krb5.conf. |
| RUTA A LA TECLA: | Ruta accesible a la tabla de claves en este servidor. (etc/spn.keytab) |
Una vez que haya terminado de configurar los ajustes, haga clic aquí para configurar navegadores para Kerberos SSO.
Para probar su configuración de SSO Kerberos/NTLM, haga clic aquí.
Para solucionar cualquier error, por favor haga clic aquí.
Si no tiene una cuenta de servicio, cree una nueva cuenta de usuario (cuenta de servicio) en Usuarios y equipos de Active Directory. Asegúrese de que este objeto no tenga ninguna entrada SPN (el atributo servicePrincipalName debe estar vacío) asignada.
ktpass -princ HTTP/<Server Host Name>@EXAMPLE.COM -mapuser <username@EXAMPLE.COM>
-pass password -ptype KRB5_NT_PRINCIPAL -out <PATH>\spn.keytabNOTA: Asegurar EJEMPLO.COM debe estar en mayúsculas. El principio de Kerberos distingue entre mayúsculas y minúsculas. Verifique las diferencias en la escritura en mayúsculas y minúsculas antes de ejecutar el comando keytab.
| Nombre del host del servidor: | Es el nombre de host del sitio alojado en el servidor. |
| EJEMPLO.COM: | Es el nombre de dominio de Active Directory. |
| Nombre de usuario: | Es una cuenta de servicio en Active Directory. |
| Contraseña: | Es la contraseña de la cuenta de servicio utilizada anteriormente. |
| ruta de acceso: | Ruta a una ubicación local que almacenará el archivo keytab. (C:\Temp\spn.keytab) |
Nota: El comando anterior crea un archivo de tabla de claves. Debe colocarse en el servidor del cliente donde está alojado su sitio de WordPress. El usuario que ejecuta Apache debe tener acceso completo a este archivo. El usuario debe tener permiso para acceder al archivo keytab.
chmod 644 etc/httpd/spn.keytab
yum install -y krb5-workstation krb5-devel krb5-libs mod_auth_gssapi mod_sessionNota: En las versiones más recientes de CentOS, el mod_auth_kerb ha sido obsoleto y reemplazado por el mod_auth_gssapi.
yum install mod_auth_kerbsudo apt-get -y install libapache2-mod-auth-gssapi
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
EXAMPLE.COM = {
kdc = <DNS entries pointing to your primary domain controller>: Port
admin_server = <DNS entries pointing to your primary domain controller>: Port
}
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Nota: Vuelva a colocar la ANUNCIO CONTROLADOR DE DOMINIO IP/DNS con su dirección IP/DNS. Asegurar EJEMPLO.COM debe estar en mayúsculas.
Vuelva a colocar la EJEMPLO.COM con el nombre de dominio de Active Directory.
Y asegúrese de que se pueda acceder al puerto 88 en el controlador de dominio AD desde este servidor.
<Directory "/placeholder">
AuthType Kerberos
KrbAuthRealms EXAMPLE.COM
KrbServiceName HTTP/<Server Host Name>
Krb5Keytab <PATH TO KEYTAB>
KrbMethodNegotiate on
KrbMethodK5Passwd on
require valid-user
</Directory>
LoadModule auth_gssapi_module modules/mod_auth_gssapi.so
<Directory "/placeholder">
AuthType GSSAPI
AuthName "Kerberos auth"
GssapiBasicAuth On
GssapiCredStore keytab:<PATH TO KEYTAB>
GssapiLocalName On
Require valid-user
</Directory>
Los siguientes son los componentes de la configuración anterior:
| RUTA A LA TECLA | Ruta accesible a la tabla de claves en este servidor. (etc/apache2/spn.keytab) |
| "/marcador de posición" | Ruta a la raíz del documento |
Una vez que haya terminado de configurar los ajustes, haga clic aquí para configurar navegadores para Kerberos SSO.
Para probar su configuración de SSO Kerberos/NTLM, haga clic aquí.
Para solucionar cualquier error, por favor haga clic aquí.
Nota: Supongamos que el sitio web tiene que responder en http://nombredeequipo y http://nombredeequipo.dominio.com. Tenemos que especificar estas direcciones en el atributo SPN de la cuenta de servicio.
Setspn -S http/<computer-name>.<domain-name> <domain-user-account>Ejemplo: C:\Usuarios\Administrador> setspn -S HTTP/nombre_máquina.dominio.com cuenta_servicio
Nota: "nombredeequipo.dominio.com" aquí es el nombre de equipo. Asegúrese de que se pueda resolver en el servidor de Windows que ejecuta el servicio AD.
setspn -l domain or service_accountEjemplo: C:\Usuarios\Administrador> setspn -l cuenta_servicio o C:\Usuarios\Administrador> setspn -l nombre de dominio
Nota: De forma predeterminada, hay dos proveedores disponibles: Negotiate y NTLM. Negotiate es un contenedor que utiliza Kerberos como primer método de autenticación y, si la autenticación falla, se utiliza NTLM. Por lo tanto, es necesario que Negotiate ocupe el primer lugar en la lista de proveedores.
Ejemplo:dominio.com\cuenta_servicio
Nota: Establecer useAppPoolCredentials en True significa que permitimos que IIS use la cuenta de dominio para descifrar el ticket de Kerberos de los clientes.
Inicie el violinista e inicie el navegador en el sitio web deseado. Ubique la línea de acceso al sitio web en el lado izquierdo de la ventana. Seleccione la pestaña Inspeccionar en el lado derecho de la ventana. Es evidente que Kerberos se ha utilizado para autenticar en el sitio web de IIS desde la línea "El encabezado de autorización (negociar) parece contener un ticket de Kerberos".
Una vez que haya terminado de configurar los ajustes, haga clic aquí para configurar navegadores para Kerberos SSO.
Para probar su configuración de SSO Kerberos/NTLM, haga clic aquí.
Para solucionar cualquier error, por favor haga clic aquí.
Setspn -s http/<computer-name>.<domain-name> <domain-user-account>Ejemplo: C:\Usuarios\Administrador> setspn -S HTTP/nombre_máquina.dominio.com cuenta_servicio
Nota: "nombredeequipo.dominio.com" aquí es el nombre de equipo. Asegúrese de que se pueda resolver en el servidor de Windows que ejecuta el servicio AD.
setspn -l domain\service_account
LoadModule authnz_sspi_module modules/mod_authnz_sspi.soLoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_core_module modules/mod_authz_core.so
<Directory "...../xampp/htdocs">
......
......
#Require all granted
AllowOverride None Options None
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
Require valid-user
</Directory>
Una vez que haya terminado de configurar los ajustes, haga clic aquí para configurar navegadores para Kerberos SSO.
Para probar su configuración de SSO Kerberos/NTLM, haga clic aquí.
Para solucionar cualquier error, por favor haga clic aquí.
La configuración del lado del cliente permite que el navegador respectivo utilice SPNEGO para negociar la autenticación Kerberos para el navegador. Debe asegurarse de que el navegador del sistema del usuario final esté configurado para admitir la autenticación Kerberos.
De forma predeterminada, se aplicarán los ajustes de configuración generales del navegador; no se requieren más ajustes adicionales para Internet Explorer.
De forma predeterminada, se aplicarán los ajustes de configuración general del navegador; no se requieren más ajustes adicionales para Google Chrome.
El protocolo Kerberos requiere que la hora del cliente y del servidor coincidan: si el reloj del sistema del cliente no coincide con el del servidor, la autenticación fallará. La forma más sencilla de sincronizar los relojes del sistema es utilizar un servidor de protocolo de tiempo de red (NTP).
Para verificar su configuración de keytab y kerberos, puede ejecutar los siguientes comandos:
El comando klist muestra el contenido de una tabla de claves o caché de credenciales de Kerberos. Con este comando podrás comprobar si tienes un billete válido o no.
Para enumerar todas las entradas en la tabla de claves etc/apache2/spn.keytab con marcas de tiempo.
Muestra el tipo de cifrado para la clave de sesión y el ticket y enumera las entradas en una tabla de claves.
Verifique la autenticación Kerberos con el archivo keytab.
Puede utilizar este comando en Linux para restablecer cualquier token de Kerberos en su máquina local. El comando destruye su ticket Kerberos anterior.
Puede utilizar este comando en Windows para restablecer cualquier token de Kerberos en su máquina local. El comando destruye su ticket Kerberos anterior.
<?php
var_dump($_SERVER);
?>
Nota: Elimine el archivo test.php después de verificar su configuración. Ya que contiene información valiosa.
ktutil
ktutil: read_kt <keytab_filename_1>
ktutil: read_kt <keytab_filename_2>
ktutil: read_kt <keytab_filename_3>
ktutil: write_kt spn.keytab
ktutil: quit
klist -k spn.keytab
kinit: Pre-authentication failed: Invalid argument while getting initial credentials
ktutil
addent -password -p HTTP/<Server Host Name>@EXAMPLE.COM -k 1 -e aes256-cts-hmac-sha1-96
wkt spn.keytab.
Unspecified GSS failure. Minor code may provide more information (Clock skew too great)
or
kinit: krb5_get_init_creds: Too large time skew
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Permission denied)
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Key table entry not found).
Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)
gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, ).
kinit: KDC has no support for encryption type while getting initial credentials
[libdefaults]
default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
kinit: krb5_get_init_creds: Error from KDC: CLIENT EXPIRED
or
kinit: Client's entry in database has expired while getting initial credentials
kinit: krb5_cc_get_principal: No credentials cache file found
or
kinit: krb5_get_init_creds: Error from KDC: CLIENT_NOT_FOUND
kinit : Cannot find KDC for requested realm while getting initial credentials
kinit: Preauthentication failed while getting initial credentials
kinit: Client not found in Kerberos database while getting initial credentials
kinit: Client's entry in database has expired
¿Necesitas ayuda? ¡Estamos aquí!
