You are not logged in.
I deployed GLPI 10 recently with Kerberos auth base on Ubuntu 22.04. It's simple install with mysql base on the same host. Becasue it's production install I followed best practices:
https:// glpi-install .readthedocs.io/en/latest/install/index.html#files-and-directories-locations
I set up GLPI_CONFIG_DIR, GLPI_VAR_DIR and GLPI_LOG_DIR as it is recommended and create local_define (I've impression that docs have lack of information how to do this correctly for GLPI inventory).
I set-up the rest with following tutorial: https:// www. youtube.com/watch?v=NGtERMS7S7Q
I found that our agents can't communicate with server - installed linux agent on the glpi server itself (want to use it to esxi inventory also - I don't know if it's require on the server) and try to communicate but I can't login.
To illustrate what happend on timeline:
1. Deployed glpi via GLPI-Maker
2. I add Kerberos auth
3. Found out something was broken
Base question is what do you do to authorize your end clients (glpi-agent) when you use GLPI also as a passwordless helpdesk system in your intranet?
From my point of view there are two possible solution:
1. Use Kerberos either (this can be easily made on Windows hosts but Ubuntu it's not that obvious).
2. Use Base Auth (conifigure glpi-agent accordinaly) and for Apache2 provide user and password (require .htpasswd configuration)
From this standpoint all options should work but I found that if I setup all with recommended manner the root location points to /var/www/glpi/public that require Kerberos.
On the other hand I hide login box (it's poor to show this your Windows end users) and this is besically the reason why linux machine can't communicate via Kerberos (even it's propertly conifigured member of the domain).
Simple solution for this is replace statement "Require valid-users" with "Require all granted" but it pointless if we want any authentication.
Second idea was try to made separate endpoint (path, url location) and able to connect via other authtype but from my tests it's imposible.
I tested out creating dedicated apache <Directory> block or even <Files> with basic auth (for single file /var/www/glpi/front/inventry.php) but for some reason it's been override by Kerb.
It's looks like we have to configure 2 auth providers witin Apache - kerberos and Basic HTTP Auth. It's could be working with ldap and file auth but not kerb.
https:// httpd.apache.org/docs/2.4/howto/auth.html#multprovider
AuthnProviderAlias do not work with (kerb / kerberos or even krb5)
In the conclusion I stuck in the point where I can allow user make create ticket or grab info about their workstation but no both.
Apache configuration:
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster@localhost
ServerName hd.miranet.local
DocumentRoot /var/www/glpi/public
<Directory "/var/www/glpi/public">
Options Indexes FollowSymLinks
AllowOverride All
AuthType GSSAPI
AuthName "Kerberos authenticated intranet with mod_auht_gssapi"
GssapiCredStore keytab:/etc/apache2/hd.miranet.local.keytab
GssapiAllowedMech krb5
# Show login box - this is problematic setting
GssapiBasicAuth Off
GssapiLocalName On
GssapiSSLonly On
Require valid-user # Omit kerberos auth
RewriteEngine On
# Redirect all requests to GLPI router, unless file exists.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,L]
</Directory>
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile /etc/ssl/certs/GLPI.crt
SSLCertificateFile /etc/ssl/certs/GLPI.crt
SSLCertificateKeyFile /etc/ssl/private/GLPI.key
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile /etc/ssl/certs/GLPI.crt
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/ssl/certs/
#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/apache2/ssl.crl/
#SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
# BrowserMatch "MSIE [2-6]" \
# nokeepalive ssl-unclean-shutdown \
# downgrade-1.0 force-response-1.0
</VirtualHost>
</IfModule>glpi-agent example config:
server = "https://hd.miranet.local/front/inventory.php"
ssl-fingerprint = "3JKHJKJK435H43K5J43LK654J6L45"
ca-cert-file = "/etc/glpi-agent/ca/glpi-ua.crt"
user = "tester.stoku@MIRANET.LOCAL"
password = "Password"
debug = 2glpi-agent debug:
[debug] Logger backend Stderr initialized
[debug] GLPI Agent (1.5-1)
[debug] Configuration directory: /etc/glpi-agent
[debug] Data directory: /usr/share/glpi-agent
[debug] Storage directory: /var/lib/glpi-agent
[debug] Lib directory: /usr/share/glpi-agent/lib
[debug] [target server0] Next server contact planned for Sun Oct 8 16:47:55 2023
[debug2] getAvailableTasks() : add of task Inventory version 1.13
[debug2] getAvailableTasks() : add of task RemoteInventory version 1.2
[debug2] getAvailableTasks() : add of task WakeOnLan version 2.2
[debug] Available tasks:
[debug] - Inventory: 1.13
[debug] - RemoteInventory: 1.2
[debug] - WakeOnLan: 2.2
[debug] target server0: server https://hd.miranet.local/front/inventory.php
[debug] Planned tasks for server0: RemoteInventory,WakeOnLan,Inventory
[debug] Built by Debian
[debug] Source time: 2023-06-21 13:59
[debug] Running in foreground mode
[info] target server0: server https://hd.miranet.local/front/inventory.php
[debug2] [http client] Using Compress::Zlib for compression
[info] sending prolog request to server0
[debug2] [http client] sending message:
<?xml version="1.0" encoding="UTF-8"?>
<REQUEST>
<DEVICEID>hd.miranet.local-2023-10-05-05-45-38</DEVICEID>
<QUERY>PROLOG</QUERY>
<TOKEN>12345678</TOKEN>
</REQUEST>
DEBUG: .../IO/Socket/SSL.pm:2961: new ctx 94465510480128
DEBUG: .../IO/Socket/SSL.pm:704: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:706: socket connected
DEBUG: .../IO/Socket/SSL.pm:729: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:771: using SNI with hostname hd.miranet.local
DEBUG: .../IO/Socket/SSL.pm:806: request OCSP stapling
DEBUG: .../IO/Socket/SSL.pm:822: set socket to non-blocking to enforce timeout=180
DEBUG: .../IO/Socket/SSL.pm:836: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:2805: ok=1 [1] /C=PL/ST=Somewhere/L=TelAviv/O=CORP TelAviv/CN=hd.miranet.local/C=PL/ST=Somewhere/L=TelAviv/O=CORP XYZ/CN=hd.miranet.local
DEBUG: .../IO/Socket/SSL.pm:2805: ok=1 [0] /C=PL/ST=Somewhere/L=TelAviv/O=CORP TelAviv/CN=hd.miranet.local/C=PL/ST=Somewhere/L=TelAviv/O=CORP XYZ/CN=hd.miranet.local
DEBUG: .../IO/Socket/SSL.pm:1781: scheme=www cert=94465443561184
DEBUG: .../IO/Socket/SSL.pm:1791: identity=hd.miranet.local cn=hd.miranet.local alt=7 2 hd.miranet.local 2 hd
DEBUG: .../IO/Socket/SSL.pm:839: done Net::SSLeay::connect -> 1
DEBUG: .../IO/Socket/SSL.pm:894: ssl handshake done
[debug] [http client] authentication required, submitting credentials
[error] [http client] authentication required, wrong credentials
[error] No supported answer from server at https://hd.miranet.local/front/inventory.php
DEBUG: .../IO/Socket/SSL.pm:3010: free ctx 94465510480128 open=94465510480128
DEBUG: .../IO/Socket/SSL.pm:3014: free ctx 94465510480128 callback
DEBUG: .../IO/Socket/SSL.pm:3021: OK free ctx 94465510480128If someone have any idea how to bypass and can share your own thoughts how to make it work I'm really curious.
Offline
Hi pr0way,
I think we're in the same situation as you.
We have Basic Auth in /front/inventory.php
If I install the agent without user and password, the server still receiving the inventory.
If we protect all the glpi directory, user and password come into action, and it's required to install the msi with those parameters.
We don't want to protect all glpi directory, just the inventory.
What are we missing?
Thanks in advance!
Offline