search

freeipa / freeipa-container

FreeIPA server in containers — images at https://quay.io/repository/freeipa/freeipa-server?tab=tags
https://quay.io/repository/freeipa/freeipa-server?tab=tags
Apache License 2.0
603 stars 258 forks source link

Can not login web behind SSL proxy. httpd log [wsgi:error] - '401 Unauthorized: No session cookie found' #626

Open harvey103565 opened 2 days ago

harvey103565 commented 2 days ago

I managed to deploy FreeIPA service on Kubernetes. For now it's only a clean installation for verification purposes. However, there is a weired issue, that I googled but with no luck.
FreeIPA web don't permit login and httpd error log shows:

[wsgi:error] [pid 14398:tid 14546] [remote 10.0.0.164:38842] ipa: INFO: 401 Unauthorized: No session cookie found

Not sure if this is the right place to ask for help, please let me know which module to investigate.

Deploy info FreeIPA container, which is managed by k8s statefulset controller, was started with: ipa-server-install -U --domain="idm.svc.cluster.local" --realm="IDM.SVC.CLUSTER.LOCAL" --ds-password="${DM_PASSWORD}" --admin-password="${ADMIN_PASSWORD}" --no-ntp --setup-dns --forwarder="10.0.255.68". replica: 1 headless service: freeipa namespace: idm container hostname -f: ipa-0.freeipa.idm.svc.cluster.local

Exposed k8s service # kubectl get svc -n idm web: web ClusterIP 10.0.255.159 <none> 80/TCP,443/TCP 17d app=freeipa

As tls terminated at ingress gateway, which is istio service, I have to make istio connect to backend freeipa-service web at port 80, following freeipa howtos: FreeIPA behind SSL proxy, but omit the self ssl part. Istio already has proper certificate to terminate tls. New configuration file /etc/httpd/conf.d/ipa-httprp.conf is created as:

Listen 80
<VirtualHost *:80>
    ErrorLog "logs/rp_error_log"

    <Location "/">
      Require all granted
      RequestHeader set Origin "https://ipa-0.freeipa.idm.svc.cluster.local"
      RequestHeader set Referer "https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/"
    </Location>

    ProxyPass / http://ipa-0.freeipa.idm.svc.cluster.local:8086/
    ProxyPassReverse / http://ipa-0.freeipa.idm.svc.cluster.local:8086/
</VirtualHost>

note: I changed httpd default listening port to 8086

And I also made some changes to /etc/httpd/conf.d/ipa-rewrite.conf to disable https redirect, new content as:

# VERSION 7 - DO NOT REMOVE THIS LINE

RewriteEngine on

# By default forward all requests to /ipa. If you don't want IPA
# to be the default on your web server comment this line out.
# # RewriteRule ^/$ https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui [L,NC,R=301]

# Redirect to the fully-qualified hostname. Not redirecting to secure
# port so configuration files can be retrieved without requiring SSL.
# # RewriteCond %{HTTP_HOST}    !^ipa-0.freeipa.idm.svc.cluster.local$ [NC]
# # RewriteCond %{HTTP_HOST}    !^ipa-ca.idm.svc.cluster.local$ [NC]
# # RewriteRule ^/ipa/(.*)      http://ipa-0.freeipa.idm.svc.cluster.local/ipa/$1 [L,R=301]

# Redirect to the secure port if not displaying an error or retrieving
# configuration.
# # RewriteCond %{SERVER_PORT}  !^443$
# # RewriteCond %{REQUEST_URI}  !^/ipa/(errors|config|crl)
# # RewriteCond %{REQUEST_URI}  !^/ipa/[^\?]+(\.js|\.css|\.png|\.gif|\.ico|\.woff|\.svg|\.ttf|\.eot)$
# # RewriteRule ^/ipa/(.*)      https://ipa-0.freeipa.idm.svc.cluster.local/ipa/$1 [L,R=301,NC]

# # RewriteCond %{HTTP_HOST}    ^ipa-ca.idm.svc.cluster.local$ [NC]
# # RewriteCond %{REQUEST_URI}  !^/ipa/crl
# # RewriteCond %{REQUEST_URI}  !^/(ca|kra|pki|acme)
# # RewriteRule ^/(.*)          https://ipa-0.freeipa.idm.svc.cluster.local/$1 [L,R=301]

# Rewrite for plugin index, make it like it's a static file
RewriteRule ^/ipa/ui/js/freeipa/plugins.js$    /ipa/wsgi/plugins.py [PT]

Logs & diagnose tool outputs:

For new virtualhost act as reverse proxy, Everything in logs/rp_error_log seems good.

[Wed Oct 09 09:20:53.247483 2024] [proxy:trace2] [pid 14619:tid 14633] mod_proxy.c(884): [client 127.0.0.6:37211] AH03461: attempting to match URI path '/ipa/ui/' against prefix '/' for proxying [Wed Oct 09 09:20:53.247509 2024] [proxy:trace1] [pid 14619:tid 14633] mod_proxy.c(1005): [client 127.0.0.6:37211] AH03464: URI path '/ipa/ui/' matches proxy handler 'proxy:http://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/' [Wed Oct 09 09:20:53.247522 2024] [authz_core:debug] [pid 14619:tid 14633] mod_authz_core.c(815): [client 127.0.0.6:37211] AH01626: authorization result of Require all granted: granted [Wed Oct 09 09:20:53.247533 2024] [authz_core:debug] [pid 14619:tid 14633] mod_authz_core.c(815): [client 127.0.0.6:37211] AH01626: authorization result of : granted [Wed Oct 09 09:20:53.247565 2024] [proxy:trace2] [pid 14619:tid 14633] proxy_util.c(2369): [client 127.0.0.6:37211] http: found worker http://ipa-0.freeipa.idm.svc.cluster.local:8086/ for http://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 09:20:53.247569 2024] [proxy:debug] [pid 14619:tid 14633] mod_proxy.c(1530): [client 127.0.0.6:37211] AH01143: Running scheme http handler (attempt 0), referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 09:20:53.247572 2024] [proxy_ajp:debug] [pid 14619:tid 14633] mod_proxy_ajp.c(795): [client 127.0.0.6:37211] AH00894: declining URL http://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 09:20:53.247576 2024] [proxy_fcgi:debug] [pid 14619:tid 14633] mod_proxy_fcgi.c(1069): [client 127.0.0.6:37211] AH01076: url: http://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/ proxyname: (null) proxyport: 0, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 09:20:53.247579 2024] [proxy_fcgi:debug] [pid 14619:tid 14633] mod_proxy_fcgi.c(1074): [client 127.0.0.6:37211] AH01077: declining URL http://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 09:20:53.247583 2024] [proxy:debug] [pid 14619:tid 14633] proxy_util.c(2575): AH00942: http: has acquired connection for (ipa-0.freeipa.idm.svc.cluster.local:8086) [Wed Oct 09 09:20:53.247587 2024] [proxy:debug] [pid 14619:tid 14633] proxy_util.c(2640): [client 127.0.0.6:37211] AH00944: connecting http://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/ to ipa-0.freeipa.idm.svc.cluster.local:8086, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 09:20:53.247591 2024] [proxy:debug] [pid 14619:tid 14633] proxy_util.c(2866): [client 127.0.0.6:37211] AH00947: connected /ipa/ui/ to ipa-0.freeipa.idm.svc.cluster.local:8086, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 09:20:53.247614 2024] [proxy:trace2] [pid 14619:tid 14633] proxy_util.c(3149): http: reusing backend connection 10.0.0.164:38696<>10.0.0.164:8086 [Wed Oct 09 09:20:53.247911 2024] [proxy:debug] [pid 14619:tid 14633] proxy_util.c(2591): AH00943: http: has released connection for (ipa-0.freeipa.idm.svc.cluster.local:8086)

/var/log/httpd/error_log:

[Wed Oct 09 02:30:45.170487 2024] [authz_core:debug] [pid 14400:tid 14486] mod_authz_core.c(815): [client 10.0.0.164:38842] AH01626: authorization result of Require all granted: granted, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 02:30:45.170501 2024] [authz_core:debug] [pid 14400:tid 14486] mod_authz_core.c(815): [client 10.0.0.164:38842] AH01626: authorization result of : granted, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 02:30:45.170507 2024] [auth_gssapi:debug] [pid 14400:tid 14486] mod_auth_gssapi.c(737): [client 10.0.0.164:38842] GSSapiImpersonate not On, skipping impersonation., referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 02:30:45.317192 2024] [authz_core:debug] [pid 14400:tid 14492] mod_authz_core.c(815): [client 10.0.0.164:38856] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 02:30:45.317207 2024] [authz_core:debug] [pid 14400:tid 14492] mod_authz_core.c(815): [client 10.0.0.164:38856] AH01626: authorization result of : denied (no authenticated user yet), referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 02:30:45.317217 2024] [auth_gssapi:debug] [pid 14400:tid 14492] mod_auth_gssapi.c(904): [client 10.0.0.164:38856] URI: /ipa/session/cookie, no main, no prev, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 02:30:45.404714 2024] [auth_gssapi:debug] [pid 14400:tid 14492] mod_auth_gssapi.c(1247): [client 10.0.0.164:38856] requester: admin@IDM.SVC.CLUSTER.LOCAL, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 02:30:45.408194 2024] [authz_core:debug] [pid 14400:tid 14492] mod_authz_core.c(815): [client 10.0.0.164:38856] AH01626: authorization result of Require valid-user : granted, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 02:30:45.408204 2024] [authz_core:debug] [pid 14400:tid 14492] mod_authz_core.c(815): [client 10.0.0.164:38856] AH01626: authorization result of : granted, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 02:30:45.408221 2024] [lookup_identity:debug] [pid 14400:tid 14492] mod_lookup_identity.c(445): [client 10.0.0.164:38856] invoked for user admin@IDM.SVC.CLUSTER.LOCAL, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 02:30:45.408267 2024] [core:debug] [pid 14400:tid 14492] util_cookies.c(58): [client 10.0.0.164:38856] AH00007: ap_cookie: user 'admin@IDM.SVC.CLUSTER.LOCAL' set cookie: 'ipa_session=MagBearerToken=3hx8oSEBXCj8z%2bdRnuqJOzjycnKVaWiI2SJGHXw8pAiY%2fLpo1XyNHd1e1WzR2pPcLaDOuEGjn71eqUrAOZYdS5jPhtRBdIh8xurm7JM0jz2vzNe0xAY1fPnK9LpT8BJeAM%2f9RzvzaholtojqlIrbrDHXpM%2f8Fzr78jyeJ0iTpa5Oqzq%2bU2%2b2iyDeyQDrksU4ac4568PwK7Qu5Z6Q3y9pyOwREgdEqMWGYGCq1wgEI48%3d;path=/ipa;httponly;secure;', referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 02:30:45.410006 2024] [wsgi:error] [pid 14398:tid 14546] [remote 10.0.0.164:38842] ipa: INFO: 401 Unauthorized: No session cookie found

/var/log/krb5kdc.log:

Oct 09 02:30:45 ipa-0 krb5kdc200: AS_REQ (4 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 10.0.0.164: NEEDED_PREAUTH: WELLKNOWN/ANONYMOUS@IDM.SVC.CLUSTER.LOCAL for krbtgt/IDM.SVC.CLUSTER.LOCAL@IDM.SVC.CLUSTER.LOCAL, Additional pre-authentication required Oct 09 02:30:45 ipa-0 krb5kdc200: closing down fd 11 Oct 09 02:30:45 ipa-0 krb5kdc200: AS_REQ (4 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 10.0.0.164: ISSUE: authtime 1728441045, etypes {rep=aes256-cts-hmac-sha384-192(20), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, WELLKNOWN/ANONYMOUS@IDM.SVC.CLUSTER.LOCAL for krbtgt/IDM.SVC.CLUSTER.LOCAL@IDM.SVC.CLUSTER.LOCAL Oct 09 02:30:45 ipa-0 krb5kdc200: closing down fd 11 Oct 09 02:30:45 ipa-0 krb5kdc200: AS_REQ (4 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 10.0.0.164: NEEDED_PREAUTH: admin@IDM.SVC.CLUSTER.LOCAL for krbtgt/IDM.SVC.CLUSTER.LOCAL@IDM.SVC.CLUSTER.LOCAL, Additional pre-authentication required Oct 09 02:30:45 ipa-0 krb5kdc200: closing down fd 11 Oct 09 02:30:45 ipa-0 krb5kdc200: AS_REQ (4 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 10.0.0.164: ISSUE: authtime 1728441045, etypes {rep=aes256-cts-hmac-sha384-192(20), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, admin@IDM.SVC.CLUSTER.LOCAL for krbtgt/IDM.SVC.CLUSTER.LOCAL@IDM.SVC.CLUSTER.LOCAL Oct 09 02:30:45 ipa-0 krb5kdc200: closing down fd 11 Oct 09 02:30:45 ipa-0 krb5kdc200: TGS_REQ (4 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 10.0.0.164: ISSUE: authtime 1728441045, etypes {rep=aes256-cts-hmac-sha384-192(20), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, admin@IDM.SVC.CLUSTER.LOCAL for HTTP/ipa-0.freeipa.idm.svc.cluster.local@IDM.SVC.CLUSTER.LOCAL Oct 09 02:30:45 ipa-0 krb5kdc200: closing down fd 11

# ipa-pkinit-manage status

PKINIT is enabled The ipa-pkinit-manage command was successful

# klist

Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin@IDM.SVC.CLUSTER.LOCAL

Valid starting Expires Service principal 10/09/24 11:10:40 10/10/24 10:50:16 krbtgt/IDM.SVC.CLUSTER.LOCAL@IDM.SVC.CLUSTER.LOCAL 10/09/24 11:10:48 10/10/24 10:50:16 HTTP/ipa-0.freeipa.idm.svc.cluster.local@IDM.SVC.CLUSTER.LOCAL

# ipa -v ping

-------------------------------------------- IPA server version 4.11.0. API version 2.253 --------------------------------------------

# httpd logs withipa -v ping``

[Wed Oct 09 07:50:38.793577 2024] [:warn] [pid 14619:tid 14622] [client 10.0.0.164:48774] failed to set perms (3140) on file (/run/ipa/ccaches/admin@IDM.SVC.CLUSTER.LOCAL-4aVFJq)!, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/xml [Wed Oct 09 07:53:02.158910 2024] [wsgi:error] [pid 14398:tid 14546] [remote 10.0.0.164:51260] ipa: INFO: [jsonserver_session] admin@IDM.SVC.CLUSTER.LOCAL: ping/1(version='2.253'): SUCCESS

# ipa -vv pwpolicy-show global_policy

ipa: INFO: Request: {
    "id": 0,
    "method": "pwpolicy_show/1",
    "params": [
        [
            "global_policy"
        ],
        {
            "version": "2.253"
        }
    ]
}
ipa: INFO: Response: {
    "error": null,
    "id": 0,
    "principal": "admin@IDM.SVC.CLUSTER.LOCAL",
    "result": {
        "result": {
            "cn": [
                "global_policy"
            ],
            "dn": "cn=global_policy,cn=IDM.SVC.CLUSTER.LOCAL,cn=kerberos,dc=idm,dc=svc,dc=cluster,dc=local",
            "krbmaxpwdlife": [
                "90"
            ],
            "krbminpwdlife": [
                "1"
            ],
            "krbpwdfailurecountinterval": [
                "60"
            ],
            "krbpwdhistorylength": [
                "0"
            ],
            "krbpwdlockoutduration": [
                "600"
            ],
            "krbpwdmaxfailure": [
                "6"
            ],
            "krbpwdmindiffchars": [
                "0"
            ],
            "krbpwdminlength": [
                "8"
            ],
            "passwordgracelimit": [
                "-1"
            ]
        },
        "summary": null,
        "value": "global_policy"
    },
    "version": "4.11.0"
}
  Group: global_policy
  Max lifetime (days): 90
  Min lifetime (hours): 1
  History size: 0
  Character classes: 0
  Min length: 8
  Max failures: 6
  Failure reset interval: 60
  Lockout duration: 600
  Grace login limit: -1

# httpd logs with# ipa -vv pwpolicy-show global_policy``

[Wed Oct 09 07:55:33.817369 2024] [:warn] [pid 14619:tid 14628] [client 10.0.0.164:53852] failed to set perms (3140) on file (/run/ipa/ccaches/admin@IDM.SVC.CLUSTER.LOCAL-2mDohG)!, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/xml [Wed Oct 09 07:55:34.299319 2024] [wsgi:error] [pid 14399:tid 14543] [remote 10.0.0.164:53852] ipa: INFO: [jsonserver_session] admin@IDM.SVC.CLUSTER.LOCAL: pwpolicy_show/1('global_policy', version='2.253'): SUCCESS

About 'failed to set perms (3140)' in logs , Here I found disscussions，And seems not a issues. freeipa-container issue #282 fedora #7032

adelton commented 2 days ago

On what URL do you attempt to access that SSL ingress gateway? Is it possible that the last paragraph from https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy

In this example we have set up the proxy with the same hostname as the FreeIPA server. If the proxy needs to use different hostname, approach from FreeIPA behind HTTP proxy with different hostname can be used.

applies to your situation and you need to also configure proper rewrite of the hostnames and cookies?

harvey103565 commented 2 days ago

OH.. I forgot the cookies.

As per described in FreeIPA behind HTTP proxy with different hostname. Just added new line into my configuration. /etc/http/conf.d/ipa-httprp.conf. It looks now:

Listen 80

<VirtualHost *:80>
  ErrorLog "logs/rp_error_log"

  <Location "/">
    Require all granted
    # # RequestHeader set Origin "https://ipa-0.freeipa.idm.svc.cluster.local"
    RequestHeader edit Referer "https://ipa.cdyhamc.com/ipa/ui/" "https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/"
    # ADDING THIS LINE
    ProxyPassReverseCookieDomain ipa-0.freeipa.idm.svc.cluster.local ipa.company.top
  </Location>

  ProxyPass / http://ipa-0.freeipa.idm.svc.cluster.local:8086/
  ProxyPassReverse / http://ipa-0.freeipa.idm.svc.cluster.local:8086/
</VirtualHost>

But still not working. Good news is that I do see cookie in httpd: logs/errror_log, bad one is that we did not see cookie from browser: Edge/Chrome/Firefox... , There is even no set-cookie header in freeipa response header. "ipa.company.top" is the domain name used to access the gateway.

[Wed Oct 09 14:22:44.971546 2024] [lookup_identity:debug] [pid 15231:tid 15247] mod_lookup_identity.c(445): [client 10.0.0.164:37402] invoked for user admin@IDM.SVC.CLUSTER.LOCAL, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 14:22:44.971589 2024] [core:debug] [pid 15231:tid 15247] util_cookies.c(58): [client 10.0.0.164:37402] AH00007: ap_cookie: user 'admin@IDM.SVC.CLUSTER.LOCAL' set cookie: 'ipa_session=MagBearerToken=5uOiLo4uUPcWlnJxawClUr2AOTa1xBeIuHWwUa5rtv5hnDf3ZEei6k%2bt7Oofbq4pud7avT10t6ZKFsXVvT0eTt6BlZNrx%2bfnTZiakVGlFKy7HxmLbON5ubBPLICc%2fJh2DP94pfqrDeenqG5QGdE4yuyR2LmCzLOGgRsON6M1nVkaS3390WmyBwZhP5nvNYqDwu%2fVx4t2%2fJpN7iXq6WhQHkaPIDYPAP%2fljZq2ihkFNvk%3d;path=/ipa;httponly;secure;', referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Wed Oct 09 14:22:44.973508 2024] [wsgi:error] [pid 15071:tid 15216] [remote 10.0.0.164:37430] ipa: INFO: 401 Unauthorized: No session cookie found

adelton commented 2 days ago

If from the point of view of the FreeIPA server its "self" URL is http://ipa-0.freeipa.idm.svc.cluster.local:8086/, why do you have that https://ipa-0.freeipa.idm.svc.cluster.local/ in RequestHeader set Origin, RequestHeader set Referer, and RequestHeader edit Referer? BTW, that ipa.cdyhamc.com should likely be changed to ipa.company.top as well.

There is even no set-cookie header in freeipa response header

Where do you observe that response? In browser's Developer Tools' Network traffic, or with tcpdump somewhere along the line?

harvey103565 commented 2 days ago

BTW, that ipa.cdyhamc.com should likely be changed to ipa.company.top as well.

This is a typo while editing reply, Not a error in my conf.

Where do you observe that response? In browser's Developer Tools' Network traffic, or with tcpdump somewhere along the line?

Browser's Developer Tools' Network traffic. I also tried to finger out how to print complet http package forwarded via httpd-mod-proxy, which is create with <VirtuaHost *:80>, but not work.

FreeIPA server its "self" URL is http://ipa-0.freeipa.idm.svc.cluster.local:8086/

Made a test with configuration, set Origin header is not necessary, edit Referer has been changed to ipa-0.freeipa.idm.svc.cluster.local:8086. Then web loading process stuck at POST https://ipa.company.top/ipa/i18n_messages， server reply error with response code 200. (see attached pic below)

Listen 80

<VirtualHost *:80>
  ErrorLog "logs/rp_error_log"

  <Location "/">
    Require all granted
    RequestHeader edit Referer "https://ipa.company.top/ipa/ui/" "https://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/"
    ProxyPassReverseCookieDomain ipa-0.freeipa.idm.svc.cluster.local ipa.company.top
  </Location>

  ProxyPass / http://ipa-0.freeipa.idm.svc.cluster.local:8086/
  ProxyPassReverse / http://ipa-0.freeipa.idm.svc.cluster.local:8086/
</VirtualHost>

image

server response body:

result: null error: Object: code: 911 message "Missing or invalid HTTP Referer, https://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/" data: Object referer: "https://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/" name:"RefererError" id: null principal:"UNKNOWN" version "4.11.0"

Also tried adding #port 8086 to ProxyPassReverseCookieDomain, still not work. I got this from httpd - logs/error_log , and do not see the HOST field in 'set-cookie'. Could this be the reason?

[Thu Oct 10 01:36:48.930203 2024] [core:debug] [pid 16257:tid 16344] util_cookies.c(58): [client 10.0.0.164:57034] AH00007: ap_cookie: user 'admin@IDM.SVC.CLUSTER.LOCAL' set cookie: 'ipa_session=MagBearerToken=%2fO8fKmHAYXNgReugWwvZBHOSFE%2fYX35qe4zNUqOlnw7Gz4lEvHJeujWClpU%2f2Vk3K2o7u5%2bQWn8N88ZgaR0li0CRYhE1FSfHg%2fHTidk5bAxaVWjioW5mdJJPcgMzSqhWPNAS%2bd6Mafa9TJ6jOV4kxMHNkDzDTKSoTNh4631WkM%2bGylY8ruS2o0J1Ufce1mlvVhfSRDHSvhWff6docpjyiMwHX2HtbO%2fMLxGm1decyy8%3d;path=/ipa;httponly;secure;'

adelton commented 1 day ago

You have https://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/ in that RequestHeader edit Referer. Should that really be https?

harvey103565 commented 1 day ago

You have https://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/ in that RequestHeader edit Referer. Should that really be https

Actually, browser access gateway via https://ipa.company.top/ipa/ui/. Since tls is terminated at gateway, so gateway connect to mod_proxy viahttp://ipa.company.top/ipa/ui/. ProxyPass & RequestHeader edit happens here. Then the header & url that proxy send to ipa-web service changes into http://ipa-0.freeipa.idm.svc.cluster.local:8086/ipa/ui/.

Freeipa reject access if I set RequestHeader to http://, the web become totally not accessable. I guess it is because freeipa server ask for mandatory https access.

adelton commented 1 day ago

On the FreeIPA server side, the important thing is for the protocol://host:port part of the referrer header to be the same as the URL of the current request, that's what FreeIPA code checks, IIRC. So you cannot just mix'n'match http and https.

As for

Freeipa reject access if I set RequestHeader to http://, the web become totally not accessable. I guess it is because freeipa server ask for mandatory https access.

-- yes, that's what the FreeIPA configuration does by default and that's why in FreeIPA behind SSL proxy we comment out (among others) that

 RewriteCond %{SERVER_PORT}  !^443$

line which does that enforcement.

Now those documents are over eight years old, so it is well possible that something else somewhere else is at play and needs to be configured on top of what we list there. But the principles still stand.

harvey103565 commented 1 day ago

I did some test which protocol://host:port parts are guaranteed to be consistent with the source.

Now my configuration file looks:

Listen 8086

<VirtualHost *:8086>
  ErrorLog "logs/rp_log"

  <Location "/">
    Require all granted
    RequestHeader edit Referer "https://ipa.company.top/ipa/ui/" "https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/"
    ProxyPassReverseCookieDomain ipa-0.freeipa.idm.svc.cluster.local ipa.company.top
  </Location>

  SSLProxyEngine on
  ProxyPass / https://ipa-0.freeipa.idm.svc.cluster.local/
  ProxyPassReverse / https://ipa-0.freeipa.idm.svc.cluster.local/
</VirtualHost>

This time web ui complain 'Your session has expired.' image

However krb5kdc.log shows that ticket should be issued very recently.

Oct 10 11:48:51 ipa-0 krb5kdc200: TGS_REQ (4 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 10.0.0.164: ISSUE: authtime 1728560931, etypes {rep=aes256-cts-hmac-sha384-192(20), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, admin@IDM.SVC.CLUSTER.LOCAL for HTTP/ipa-0.freeipa.idm.svc.cluster.local@IDM.SVC.CLUSTER.LOCAL

error_log has something new

... [Thu Oct 10 11:48:51.648298 2024] [core:debug] [pid 17700:tid 17799] util_cookies.c(58): [client 10.0.0.164:53812] AH00007: ap_cookie: user 'admin@IDM.SVC.CLUSTER.LOCAL' set cookie: 'ipa_session=MagBearerToken=7IKJEojnZ1KIlKYyuqiSK8CuzWBXgEgkAuDN0pgemsqkwSO5WjA%2fuaNexsC%2fiqv8LgnFZ%2bTZXexySfHsNuoEWK%2fsyst4fFjf5YaR0JlJqACEzIerMZ%2biyVs1%2ffcw9M3yQETXQrmixwvhJ637oYqjIZz9oJSww5coRXofhMcqgsgSsNc2jYmUf68RBh9%2bs7nF7esQ5XUPsApILbA8wfCVgpm1cAaEe%2fUIGW2r4jjp%2bQU%3d;path=/ipa;httponly;secure;' [Thu Oct 10 11:48:51.764623 2024] [auth_gssapi:error] [pid 17700:tid 17781] [client 10.0.0.164:57744] GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [An unsupported mechanism was requested (Unknown error)], referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Thu Oct 10 11:48:51.875705 2024] [auth_gssapi:error] [pid 17700:tid 17784] [client 10.0.0.164:57744] GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [An unsupported mechanism was requested (Unknown error)], referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/

Everything good in rp_log for every connection

... [Thu Oct 10 11:48:51.844084 2024] [proxy:debug] [pid 17700:tid 17788] proxy_util.c(2866): [client 127.0.0.6:56299] AH00947: connected /ipa/session/loginkerberos?=1728560222437 to ipa-0.freeipa.idm.svc.cluster.local:443, referer: https://ipa-0.freeipa.idm.svc.cluster.local/ipa/ui/ [Thu Oct 10 11:48:51.844105 2024] [proxy:trace2] [pid 17700:tid 17788] proxy_util.c(3149): https: reusing backend connection 10.0.0.164:57744<>10.0.0.164:443 [Thu Oct 10 11:48:51.876140 2024] [proxy:debug] [pid 17700:tid 17788] proxy_util.c(2591): AH00943: https: has released connection for (ipa-0.freeipa.idm.svc.cluster.local:443)

Does that mean I've made one step forward? Because, from Browser F12 tool, there is still no cookies / ipa_sessions set int response headers. And freeipa response to the login request is

Unable to verify your Kerberos credentials Please make sure that you have valid Kerberos tickets (obtainable via kinit), and that you have configured your browser correctly.

Thank you.

adelton commented 1 day ago

It is not completely clear to me where in the setup that mod_proxy on port 8086 is located.

But anyway, if the Set-Cookie HTTP response headers don't reach the browser, I would really be looking at the Istio configuration, to see if the Ingress Gateway may be stripping them off. Or test while bypassing it by creating some tunnel to reach the idm:web Service directly.