I am working on getting GitLab integrated with AD FS 5.0 and started by following this guide (configuring the claims policies identically): https://smartersoft.nl/2017/11/configure-sso-with-gitlab/
Things look good and I am passed between GitLab and AD FS, sign in, and am taken back to GitLab where I’m greeted by a 404 page. In reviewing logs, I see the following in production.log:
Started POST "/users/auth/saml" for 192.168.200.115 at 2019-06-03 16:41:47 -0700
Processing by Gitlab::RequestForgeryProtection::Controller#index as HTML
Parameters: {"authenticity_token"=>"[FILTERED]"}
Completed 200 OK in 0ms (ActiveRecord: 0.0ms)
Started GET "/-/metrics" for 127.0.0.1 at 2019-06-03 16:41:59 -0700
Processing by MetricsController#index as HTML
Completed 200 OK in 2ms (Views: 0.4ms | ActiveRecord: 0.0ms)
Started POST "/" for 192.168.200.115 at 2019-06-03 16:42:02 -0700
ActionController::RoutingError (No route matches [POST] "/"):
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/request_context.rb:26:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:29:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'
No errors are generated in AD FS On this event. Any ideas on what I’m missing or what log files I should review for additional clues?
Thanks!
I dug around in the logs a bit more and turned up a little more info about the POST request that gets sent:
2019-06-04_02:11:36.77774 gitlab.foo.com 71.238.125.240:0 - - [2019/06/03:19:11:36 -0700] "POST / HTTP/1.1" 404 3108 "https://sso.foo.com/adfs/ls/?SAMLRequest=fZFba8JAEIX%2FSt72KeZiTHVJAkEpCLYUrX3oS1njRBf2ku5Mevn3zSqlFlpfh%2B%2BcOXOmQKFVx%2BuejmYNrz0gBTUiOJLWzK3BXoPbgHuTDWzXq5IdiTrkUXSQpMRuJPROgiFJaFXvNThqrGbBYjCSRvjJjwbR%2FiOIxL7FSGHEguWiZC8CsraZ5lmYT8QuzPJ0Es7aNA9hOhkDJCCm%2Bc2AIvawNEjCUMnSOJmFcR7G2WOc8iTh4%2FyZBU%2Fg8BQiHcUs%2BNDKIPc3l6x3hluBErkRGpBTwzf13YoPIBffFVxKuuuazlmyjVWsKjzNT%2Blc9XdhR%2Bv7Ofjbi%2BgSL84PuR%2Fsl4sHq2TzGdRK2fe5A0FQMnI9sODWOi3oeiA%2FkfuwPaG880UgDbtZVJ13%2Fv579QU%3D" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 0.010
I have a hunch after reviewing my config. More soon.
Figured it out! I for some reason was missing /users/auth/saml/callback from the end of my assertion_consumer_service_url argument in the SAML config. I sorted that out once I realized based on the additional logging for the POST request that I was submitting the returned SSO session info to the wrong place. Users are being generated for successful SSO logins! Beautiful.
1 Like
Hey @carterk, thanks for sharing the follow up and fix with everyone. It’s really appreciated!
1 Like