Setting Up Kerberos Authentication for 1C: Linux Web Server with Windows Application Server
When publishing a 1C database on a Linux web server with a Windows application server, standard authentication setup guides often fall short. Even if the application server's technical log shows the user account passed from the web server, the platform still prompts for login credentials. The root cause is the absence of an SPN record for the service account running the 1C application server.
This detail is missing from most tutorials, including popular articles on Infostart. The solution was discovered experimentally by studying Kerberos authentication in Linux and Windows.
Infrastructure Requirements
The scenario assumes:
- A web server (Apache/Nginx) on Linux with an NTLM/Kerberos module.
- A 1C application server on Windows Server.
- An Active Directory (AD) for account management.
- IIS or a similar service on the 1C server to handle requests.
Preliminary setup includes publishing the database via the web server, configuring mod_auth_kerb (for Apache) or nginx with Lua scripts to pass authentication headers. The 1C log shows the transmitted account, but authentication fails.
Troubleshooting the Issue
Check the application server's technical log (startup parameters: -reg or via the cluster console). Look for entries like:
{User: domain\username} from web-server
If the account is visible but credential prompts persist, the issue is with the SPN.
Diagnostic steps:
- Run
setspn -Q /for the 1C service account (e.g.,svc_1c). - Verify the absence of an SPN in the output.
- Test access via a browser supporting NTLM (IE/Edge in Intranet zone).
- Check web server logs:
grep -i kerberos /var/log/apache2/error.log.
Solution: Adding an SPN Record
Create an SPN record for the service account running the application server. The SPN value is arbitrary—it's not used in traffic but required for 1C's internal authentication logic.
Command on DC or machine with RSAT:
setspn -S HTTP/fakespn.svc_1c.domain.local svc_1c
Where:
HTTP/fakespn.svc_1c.domain.localis a fictitious SPN.svc_1cis the 1C service account.
Verify with: setspn -L svc_1c. After adding, restart the application server and test access.
Authentication will work without credential prompts. The reason: the 1C platform checks for an SPN before accepting Kerberos/NTLM tokens.
Additional Kerberos Settings
- Keytab on Linux: Use
ktutilto add a key for the service principalHTTP/webserver.domain.local. - krb5.conf: Specify realm and KDC in
/etc/krb5.conf.
[realms]
DOMAIN.LOCAL = {
kdc = dc.domain.local
}
- Apache config (mod_auth_kerb):
<Location /1c>
AuthType Kerberos
AuthName "Kerberos Login"
KrblAuthRealms DOMAIN.LOCAL
KrbMethodNegotiate On
KrbsaveCredentials Off
</Location>
Key Points
- SPN is mandatory: Even a fake SPN unlocks 1C authentication.
- Logs for debugging: Use the 1C technical log and web server error.log.
- Service account: Run the 1C server under a domain account with appropriate privileges.
- Testing: Use
kiniton Linux to verify Kerberos. - Security: Limit SPNs to necessary services only.
— Editorial Team
No comments yet.