No edit summary Tag: 2017 source edit |
No edit summary Tag: 2017 source edit |
||
| Line 1: | Line 1: | ||
KitsNet applications such as MediaWiki and Grafana authenticate users against the KNADA Active Directory domain using LDAP/LDAPS. | KitsNet applications such as MediaWiki and Grafana authenticate users against the KNADA Active Directory domain using LDAP/LDAPS. | ||
A failed login does ‘’‘not’’’ necessarily indicate an LDAP server, TLS, CA, or application configuration problem. In particular, an expired KNADA user password may be presented by applications only as a generic authentication failure. | A failed login does ‘’‘not’’’ necessarily indicate an LDAP server, TLS, CA, or application configuration problem. In particular, an expired KNADA user password may be presented by applications only as a generic authentication failure. | ||
Latest revision as of 14:22, 27 September 2026
KitsNet applications such as MediaWiki and Grafana authenticate users against the KNADA Active Directory domain using LDAP/LDAPS. A failed login does ‘’‘not’’’ necessarily indicate an LDAP server, TLS, CA, or application configuration problem. In particular, an expired KNADA user password may be presented by applications only as a generic authentication failure.
1 Recommended Diagnostic Order[edit | edit source]
When one or more LDAP-authenticated applications reject a user’s credentials, use the following sequence before changing application configuration.
1.1 Check the affected KNADA user account[edit | edit source]
On a Samba AD domain controller, such as frangelico:
sudo samba-tool user show USERNAME
Review the account state and password information for indications that the password has expired or that the account is otherwise restricted.
1.2 Test the user’s password directly over LDAPS[edit | edit source]
From a system with the KNADA CA installed:
ldapwhoami \
-x \
-H ldaps://frangelico.knada.lan.kitsnet.us:636 \
-D 'USERNAME@knada.lan.kitsnet.us' \
-W
A successful authentication returns the authenticated LDAP identity. If this fails, do not immediately assume that TLS or LDAP connectivity is broken. Check the user’s password expiration and account state first.
1.3 Test Kerberos authentication[edit | edit source]
A direct Kerberos test provides an additional check of the user’s KNADA credential:
kdestroy 2>/dev/null || true
kinit USERNAME@KNADA.LAN.KITSNET.US
klist
A successful kinit followed by a valid TGT in klist confirms that the user’s password is accepted by Active Directory.
1.4 Verify application service-account LDAP access[edit | edit source]
Applications normally use a service account to search Active Directory before authenticating the individual user. For the Wiki, the service account is:
CN=svc-wiki-ldap,CN=Users,DC=knada,DC=lan,DC=kitsnet,DC=us
Verify that the application service account can: establish an LDAPS connection; validate the KNADA server certificate; bind successfully; search the KNADA directory. A successful service-account bind proves that the application’s LDAP infrastructure is substantially healthy, but it does ‘’‘not’’’ prove that an individual user’s password is valid.
1.5 Verify TLS and CA trust only if necessary[edit | edit source]
The current KNADA LDAP CA is:
O=KitsNet
OU=KNADA LDAP
CN=KitsNet KNADA LDAP CA 2026
SHA-256 fingerprint:
A1:26:57:8E:37:05:52:65:2E:26:7E:48:B0:66:7A:5D:04:4F:C8:BB:A3:4E:E8:B7:12:97:A1:3F:A3:28:15:4F
The application-specific CA bundle used by Wiki and other Swarm services contains three certificates: Historical Frangelico Samba-generated CA Historical Emperador Samba-generated CA Current KitsNet KNADA LDAP CA 2026 When inspecting a multi-certificate PEM bundle, note that:
openssl x509 -in bundle.pem -noout -subject -issuer
displays only the ‘’‘first certificate’’’ in the file. Do not conclude that the bundle lacks the current CA based solely on that command. Split or enumerate all certificates in the bundle before diagnosing it as stale.
2 September 2026 Incident[edit | edit source]
In September 2026, KNADA authentication failed simultaneously in MediaWiki and Grafana. Initial investigation verified: IPv4 and IPv6 connectivity to both KNADA domain controllers; LDAP and LDAPS availability; successful TLS certificate validation; correct application CA bundles; successful Wiki service-account binds to both Frangelico and Emperador; successful LDAP directory searches from the running Wiki container. The actual cause was that the affected user’s KNADA password had expired. Neither MediaWiki nor Grafana clearly reported the password-expired condition to the user. Both presented the condition as a generic login/authentication failure. This incident established the following troubleshooting rule: ‘’‘When multiple LDAP-authenticated applications reject the same user’s otherwise known-good credentials, check that user’s AD password/account state before changing LDAP, TLS, CA, or application configuration.’’’
3 Host CA Trust Note[edit | edit source]
During the same investigation, it was discovered that several Rocky Linux systems did not have the current KNADA LDAP CA installed in their system trust store. This was corrected separately through the KitsNet Ansible CA-distribution process. That host-trust issue was a valid configuration defect, but it was ‘’‘not’’’ the cause of the MediaWiki and Grafana login failures in this incident because those applications already used their own correct KNADA CA bundles.
