We have some web-portal on apache+nginx+php. It works on server without any problems and has sso authentification for AD. users implemented with kerberos+ntlm. But after migration of this service to cluster (using the same docker image) we get classic problem for kerberos+ntlm case:
[Wed Sep 21 11:03:12.071238 2022] [authz_core:debug] [pid 17:tid 139730998875904] mod_authz_core.c(809): [client 127.0.0.1:32876] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer:
[Wed Sep 21 11:03:12.071262 2022] [authz_core:debug] [pid 17:tid 139730998875904] mod_authz_core.c(809): [client 127.0.0.1:32876] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer:
[Wed Sep 21 11:03:12.071281 2022] [auth_kerb:debug] [pid 17:tid 139730998875904] src/mod_auth_kerb.c(1954): [client 127.0.0.1:32876] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer:
[Wed Sep 21 11:03:12.175811 2022] [authz_core:debug] [pid 17:tid 139731007268608] mod_authz_core.c(809): [client 127.0.0.1:32880] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer:
[Wed Sep 21 11:03:12.175829 2022] [authz_core:debug] [pid 17:tid 139731007268608] mod_authz_core.c(809): [client 127.0.0.1:32880] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer:
[Wed Sep 21 11:03:12.175845 2022] [auth_kerb:debug] [pid 17:tid 139731007268608] src/mod_auth_kerb.c(1954): [client 127.0.0.1:32880] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer:
[Wed Sep 21 11:03:12.175866 2022] [auth_kerb:debug] [pid 17:tid 139731007268608] src/mod_auth_kerb.c(1295): [client 127.0.0.1:32880] Acquiring creds for HTTP/PORTAL-0@AD.TRANSCAPITAL.COM, referer:
[Wed Sep 21 11:03:12.177249 2022] [auth_kerb:debug] [pid 17:tid 139731007268608] src/mod_auth_kerb.c(1708): [client 127.0.0.1:32880] Verifying client data using KRB5 GSS-API , referer:
[Wed Sep 21 11:03:12.177266 2022] [auth_kerb:debug] [pid 17:tid 139731007268608] src/mod_auth_kerb.c(1724): [client 127.0.0.1:32880] Client didn't delegate us their credential, referer:
[Wed Sep 21 11:03:12.177274 2022] [auth_kerb:debug] [pid 17:tid 139731007268608] src/mod_auth_kerb.c(1752): [client 127.0.0.1:32880] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module.
Check your IE configuration.,
[Wed Sep 21 11:03:12.177283 2022] [auth_kerb:debug] [pid 17:tid 139731007268608] src/mod_auth_kerb.c(1155): [client 127.0.0.1:32880] GSS-API major_status:00010000, minor_status:00000000, referer:
[Wed Sep 21 11:03:12.177300 2022] [auth_kerb:error] [pid 17:tid 139731007268608] [client 127.0.0.1:32880] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error), referer:
I know there is lots of solutions in net but it would be a case if authentification wasn't work at all. But there is no problems on original server only on kuber.
As I believe there is problem with ports because ntlm uses dynamic range 49152-65535 but on kuber service has only one nodeport opened (Cluster has connection to the same databases and resources, so i can't imagine another reason except for ports misdirection). What should i do to return sso functional? Pod description:
Name: portal
Namespace: portal
Labels: app.kubernetes.io/name=portal
fluxcd.io/sync-gc-mark=sha256.xMGDWmxWrK8SQwwnbLsRq9jGfZUbS6RIrrTbyHcBrPM
Annotations: fluxcd.io/sync-checksum: cd7050714e06853bec0eed8c03f5f83326fea8ff
Selector: app.kubernetes.io/name=portal
Type: LoadBalancer
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.233.16.136
IPs: 10.233.16.136
IP: 10.200.103.207
LoadBalancer Ingress: 10.200.103.207
Port: nginx 80/TCP
TargetPort: 80/TCP
**NodePort: nginx 30126/TCP**
Endpoints: 10.233.105.82:80
Session Affinity: None
External Traffic Policy: Cluster