SPN pour l'authentification 1C sur serveur web Linux

Configuration de l'authentification Kerberos pour 1C : Serveur Web Linux avec Serveur d'Application Windows

Lors de la publication d'une base de données 1C sur un serveur web Linux avec un serveur d'application Windows, les guides de configuration d'authentification standard sont souvent insuffisants. Même si le journal technique du serveur d'application indique que le compte utilisateur est transmis par le serveur web, la plateforme demande toujours des identifiants de connexion. La cause racine est l'absence d'un enregistrement SPN pour le compte de service exécutant le serveur d'application 1C.

Ce détail manque dans la plupart des tutoriels, y compris les articles populaires sur Infostart. La solution a été découverte expérimentalement en étudiant l'authentification Kerberos sous Linux et Windows.

Exigences d'infrastructure

Le scénario suppose :

• Un serveur web (Apache/Nginx) sur Linux avec un module NTLM/Kerberos.
• Un serveur d'application 1C sur Windows Server.
• Un Active Directory (AD) pour la gestion des comptes.
• IIS ou un service similaire sur le serveur 1C pour traiter les requêtes.

La configuration préliminaire inclut la publication de la base de données via le serveur web, la configuration de mod_auth_kerb (pour Apache) ou de nginx avec des scripts Lua pour transmettre les en-têtes d'authentification. Le journal 1C montre le compte transmis, mais l'authentification échoue.

Dépannage du problème

Vérifiez le journal technique du serveur d'application (paramètres de démarrage : -reg ou via la console du cluster). Recherchez des entrées comme :

{User: domain\username} from web-server

Si le compte est visible mais que les invites d'identification persistent, le problème vient du SPN.

Étapes de diagnostic :

• Exécutez setspn -Q / pour le compte de service 1C (par exemple, svc_1c).
• Vérifiez l'absence d'un SPN dans la sortie.
• Testez l'accès via un navigateur prenant en charge NTLM (IE/Edge en zone Intranet).
• Consultez les journaux du serveur web : grep -i kerberos /var/log/apache2/error.log.

Solution : Ajout d'un enregistrement SPN

Créez un enregistrement SPN pour le compte de service exécutant le serveur d'application. La valeur du SPN est arbitraire—elle n'est pas utilisée dans le trafic mais requise pour la logique d'authentification interne de 1C.

Commande sur le DC ou une machine avec RSAT :

setspn -S HTTP/fakespn.svc_1c.domain.local svc_1c

Où :

• HTTP/fakespn.svc_1c.domain.local est un SPN fictif.
• svc_1c est le compte de service 1C.

Vérifiez avec : setspn -L svc_1c. Après l'ajout, redémarrez le serveur d'application et testez l'accès.

L'authentification fonctionnera sans invites d'identification. La raison : la plateforme 1C vérifie la présence d'un SPN avant d'accepter les jetons Kerberos/NTLM.

Paramètres Kerberos supplémentaires

• Keytab sur Linux : Utilisez ktutil pour ajouter une clé pour le principal de service HTTP/webserver.domain.local.
• krb5.conf : Spécifiez le royaume et le KDC dans /etc/krb5.conf.

[realms]
DOMAIN.LOCAL = {
kdc = dc.domain.local
}

• Configuration Apache (mod_auth_kerb) :

<Location /1c>
AuthType Kerberos
AuthName "Connexion Kerberos"
KrblAuthRealms DOMAIN.LOCAL
KrbMethodNegotiate On
KrbsaveCredentials Off
</Location>

Points clés

• Le SPN est obligatoire : Même un SPN fictif débloque l'authentification 1C.
• Journaux pour le débogage : Utilisez le journal technique 1C et error.log du serveur web.
• Compte de service : Exécutez le serveur 1C sous un compte de domaine avec les privilèges appropriés.
• Test : Utilisez kinit sur Linux pour vérifier Kerberos.
• Sécurité : Limitez les SPN aux services nécessaires uniquement.

— Editorial Team