Linux – Configuring kerberos/ntlm single signon with apache and sssd

apache-2.4centos7linuxmod-auth-kerbsingle-sign-on

What is the proper/cleanest way of setting up apache to support SSO using NTLM, or preferably Kerberos, with CentOS7 running sssd connected to an Active Directory domain controller?

With realmd, joining the domain is now real easy, but I was unable to get apache to work in an evening. It seems that google is not well seeded with answers on this topic as of yet.

I have gotten SSO working with SSH using gssapi with putty.
All I have done after a fresh install of CentOS 7 is run realm join --user=admin@domain.fqdn --computer-ou=OU=Servers and add default_domain_suffix to sssd.conf.

Best Answer

You need to:

Create a HTTP/hostname.fqdn@REALM.TEST service in FreeIPA
Download HTTP service keytab on the web server with ipa-getkeytab and make it accessible to (only) apache
Configure apache and mod_auth_kerb to secure some URI with Kerberos

See this example or this example. For more advanced integration between your Web service and SSSD, check Web_App_Authentication article on FreeIPA.org.

Related Solutions

Single-Signon options for Exchange 2010

We decided that the combination of adding "ClearPass" to CAS and modifying the Exchange setup was going to be too hard to maintain, so our final solution is something like the squirrelmail solution that we didn't like.

That is, we send HTML like this to the user ($something generally means an already properly escaped variable) from a button they push in our in-house portal. This is the version where forefront is simply doing a straight pass-thru:

<html>
<body onLoad="javascript:document.forms[0].submit()">
<noscript>
 <h1>Redirecting you to $title</h1>
 <p>If you are not taken to $title within 15 seconds,<br />
    please click the button below:</p>
 </noscript>
 <form method="POST"
       action="https://$exchangehost/owa/auth/owaauth.dll" 
       name="logonForm" 
       enctype="application/x-www-form-urlencoded" autocomplete="off">
   <input type="hidden" name="destination" value="https://$exchangehost/OWA/" />
   <input type="hidden" name="flags" value="0" />
   <input type="hidden" name="forcedownlevel" value="0" />
   <input type="hidden" name="trusted" value="0" />
   <input type="hidden" name="username" value="$uid" />
   <input type="hidden" name="password" value="$password" />
   <input type="hidden" name="isUtf8" value="1" />
   <noscript>
     <input type="submit" value="$title" />
   </noscript>
 </form>
 </body>
 </html>

Mainly this is from copying the login form and making everything into hidden fields, but you need to change the URL on the action from /owa/auth.owa to /owa/auth/owaauth.dll.

We also tried having forefront do the authentication to OWA, here's the form for that (the <body onLoad=...> and the rest is basically the same):

<form method="post" action="https://$exchangehost/CookieAuth.dll?Logon">
  <input type="hidden" name="curl" value="Z2FowaZ2F" />
  <input type="hidden" name="flags" value="0" />
  <input type="forcedownlevel" value="0" />
  <input type="formdir" value="1" />
  <input type="rdoPblc" value="1" />
  <input type="username" value="$domain\$uid" />
  <input type="password" value="$password" />
</form>

Apache Bad Request “Size of a request header field exceeds server limit” with Kerberos SSO

My gut says you've got a very large security token, possibly because the user is a member of a large number of groups. The AD Kerberos implementation is going to provide Apache with a Privilege Attribute Certificate (PAC) by default. This structure can be large if the user is a member of a significant number of groups. You can use the tokensz.exe tool to see the user's token size.

If this is the problem you can modify the UserAccountControl attribute of the user's account to prevent the PAC from being sent.

You may be able to get away with modifying your /etc/krb5.conf file to reference the KDC as kdc = tcp/kdc.name.here. This problem can occur if the PAC causes the token to be too large for a UDP datagram, but forcing the communication to the KDC with TCP is a possible workaround, too.

Changing that value on 1,000 users isn't difficult for your AD admins if it solves your problem.

Best Answer

Related Solutions

Single-Signon options for Exchange 2010

Apache Bad Request “Size of a request header field exceeds server limit” with Kerberos SSO

Related Topic