Trying to sort out the combination of $WebExternalAuth and and RT::Authen::External

Hoping someone can point me to where I am going wrong. I have been
trolling the wiki, cpan, this list, and Google for the last couple of
days with no luck so far. Probably something apparent that I’m
missing…

I am after the following behavior:

  • A user inside our network and on a machine my company controls
    will be auto-logged in via SSO (mod_auth_kerb)
  • Upon successful SSO login, even if it’s a first time login, the
    user info in canonicalized from our LDAP dir (Active Directory)
  • If the user cannot use SSO, the login fails gracefully back to the
    form-based login built in to RT.
  • If the user successfully authenticates via
    RT::Authen::ExternalAuth the user info is again canonicalized even if
    it’s a first time login.
  • If an email is received from a requester, the email is looked up
    in LDAP to canonicalize the user info as well.
  • If the email address does NOT exist in the LDAP directory, go
    ahead and create an account anyway using the email address as the
    username.

No prob, right??

The basics: RT 4.0.2 from source
server: debian 6.0 (Squeeze)
db: PostgreSQL
Apache2
RT running under modperl

What I have working:

If I have WebExternalAuth turned off, my LDAP connection via
RT::Authen::ExternalAuth is working just fine.

  • I have it pointed to our Active Directory server (Server 2008 R2
    if it matters).
  • A user in the directory CAN login via the form based login screen
  • If they don’t exist, the user is properly created as desired.
  • The user info is also pulled via LDAP via CanonicalizeUserInfo() as desired.

All is well.

If I turn ON $WebExternalAuth (I’m using mod_auth_kerb) I get the
following behavior:

  • The user IS logged in with SSO as desired provided they already
    have an account.
  • The user info is NOT canonicalized from the LDAP directory as I
    would like. --FAIL–
  • If the user does not exist, they ARE created, but again, the
    user info is NOT canonicalized from the directory. --FAIL–
  • Also, mod_auth_kerb, does NOT fall back to the form-based login.
    It tries to use the KrbPasswd method which I have specifically
    disabled. --FAIL–

The message I get in the RT log (via syslog) when a user logs in with
SSO seems to indicate that the user variable is not being set and
passed to the RT::Authen::ExternalAuth extension if I read the error
right. The odd thing to me, is that while the error says SSO is
failing, it most definitely is not. The user is successfully
logged in.
----- error from syslog —
Oct 14 16:41:25 rt RT: Attempting to use external auth service: LDAP_DIR1
Oct 14 16:41:25 rt RT: SSO Failed and no user to test with. Nexting
Oct 14 16:41:25 rt RT: Autohandler called ExternalAuth. Response: (0, No User)

---- info from apache error log ---- (all looks well here, I think?)
[Fri Oct 14 17:33:54 2011] [debug] src/mod_auth_kerb.c(1628): [client
172.27.146.144] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
[Fri Oct 14 17:33:54 2011] [debug] src/mod_auth_kerb.c(1240): [client
172.27.146.144] Acquiring creds for HTTP/rt.sunnysidehospital.org
[Fri Oct 14 17:33:54 2011] [debug] src/mod_auth_kerb.c(1385): [client
172.27.146.144] Verifying client data using KRB5 GSS-API
[Fri Oct 14 17:33:54 2011] [debug] src/mod_auth_kerb.c(1401): [client
172.27.146.144] Client didn’t delegate us their credential
[Fri Oct 14 17:33:54 2011] [debug] src/mod_auth_kerb.c(1420): [client
172.27.146.144] GSS-API token of length 181 bytes will be sent back
[Fri Oct 14 17:33:54 2011] [debug] src/mod_auth_kerb.c(1534): [client
172.27.146.144] kerb_authenticate_a_name_to_local_name andersjp@SCH.AD
→ andersjp

(Full disclosure, I am also receiving this message on apache startup,
but I believe it is completely unrelated…)
Oct 14 17:33:10 rt RT: The RTAddressRegexp option is not set in the
config. Not setting this option results in additional SQL queries to
check whether each address belongs to RT or not. It is especially
important to set this option if RT recieves emails on addresses that
are not in the database or config.

First, is what I want to do truly possible? Second, can anyone help me
see what I have wrong here?
Apache2 config section:

Redirect everything to https

<VirtualHost *:80>
ServerName rt.sunnysidehospital.org

Redirect permanent / https://rt.sunnysidehospital.org/

SSLEngine on SSLCertificateFile /etc/apache2/ssl/rt.sunnysidehospital.org.crt SSLCertificateKeyFile /etc/apache2/ssl/rt.sunnysidehospital.org SSLCACertificateFile /etc/apache2/ssl/sch_ca.cer

Optional apache logs for RT

ErrorLog /opt/rt4/var/log/apache2.error
TransferLog /opt/rt4/var/log/apache2.access
LogLevel debug

    AddDefaultCharset UTF-8

    DocumentRoot "/opt/rt4/share/html"
    <Location />
            SetHandler modperl
            PerlResponseHandler Plack::Handler::Apache2
            PerlSetVar psgi_app /opt/rt4/sbin/rt-server

Kerberos for Single Signon with AD

            AuthType Kerberos
            AuthName "Sunnyside Hospital Login"
            KrbMethodNegotiate on
            KrbMethodK5Passwd off

KrbMethodK4Passwd off # when I uncomment this I get an error

(Invalid command ‘KrbMethodK4Passwd’, perhaps misspelled or

defined by a module not included in the server configuration)

            KrbAuthRealms SCH.AD
            Krb5KeyTab /etc/apache2/krb5.keytab
            KrbServiceName HTTP/rt.sunnysidehospital.org
            KrbSaveCredentials off
            KrbLocalUserMapping on
            require valid-user

            Order allow,deny
            Allow from all

    </Location>

    <Perl>
            use Plack::Handler::Apache2;
            Plack::Handler::Apache2->preload("/opt/rt4/sbin/rt-server");
    </Perl>

Relevant RT_SiteConfig.pm sections:

Set( $WebExternalAuth, 1 );
Set( $WebFallBackToInternalAuth, 1 );
Set( $WebExternalGecos, undef );
Set( $WebExternalAuto, 1 );
Set( $AutoCreate, Privileged => 0 );

Set( @Plugins, qw(
RT::Authen::ExternalAuth
RT::Extension::JSGantt
RT::Extension::MergeUsers
RT::Extension::PriorityAsString
RT::Extension::ReportSpam )
);

Set( $ExternalAuthPriority,[‘LDAP_DIR1’]);
Set( $ExternalInfoPriority,[‘LDAP_DIR1’]);
Set( $ExternalServiceUsesSSLorTLS, 0);
Set( $AutoCreateNonExternalUsers, 1);

Set($ExternalSettings, { # SCH LDAP Settings
‘LDAP_DIR1’ => { ## GENERIC SECTION

            'type'                      =>  'ldap',
            'server'                    =>  'dir1.sch.ad',
            'user' => 'cn=LDAP Auth,ou=SCH Users,dc=sch,dc=ad',
            'pass'                    =>  '************',
            'base'                      =>  'dc=sch,dc=ad',

            # ALL FILTERS MUST BE VALID LDAP FILTERS ENCASED IN PARENTHESES!
            # YOU **MUST** SPECIFY A filter AND A d_filter!!

            # The filter to use to match RT-Users
            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',

            # The filter that will only match disabled users
            'd_filter' =>

‘(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)’,

            'tls'                       =>  0,
            'ssl_version'               =>  3,
            'net_ldap_args'             => [    version =>  3   ],
            #'group'                     =>  'GROUP',
            #'group_attr'                =>  'GROUP_ATTR',

            'attr_match_list'       => [    'Name',
                                            'EmailAddress'
            ],

            # The mapping of RT attributes on to LDAP attributes
            'attr_map'      =>  {   'Name' => 'sAMAccountName',
                                    'EmailAddress' => 'mail',
                                    'Organization' => 'department',
                                    'RealName' => 'cn',
                                    'ExternalAuthId' => 'sAMAccountName',
                                    'WorkPhone' => 'telephoneNumber',
                                    'MobilePhone' => 'mobile',
                                    'Address1' => 'streetAddress',
                                    'City' => 'l',
                                    'State' => 'st',
                                    'Zip' => 'postalCode',
                                    'Country' => 'co'
            }
    }

}
);

FYI, I have tested my ldap filters with ldapsearch and run them
exactly as RT puts them together (according to the logs) and can
successfully return info for both my users filter and my disabled
users filter.

Thanks in advance for the help! (And my sincere apologies for the
short novel I had to write here.)

-John Andersen

Hoping someone can point me to where I am going wrong. I have been
trolling the wiki, cpan, this list, and Google for the last couple of
days with no luck so far. Probably something apparent that I’m
missing…

I am after the following behavior:

  • A user inside our network and on a machine my company controls
    will be auto-logged in via SSO (mod_auth_kerb)
  • Upon successful SSO login, even if it’s a first time login, the
    user info in canonicalized from our LDAP dir (Active Directory)
  • If the user cannot use SSO, the login fails gracefully back to the
    form-based login built in to RT.
  • If the user successfully authenticates via
    RT::Authen::ExternalAuth the user info is again canonicalized even if
    it’s a first time login.
  • If an email is received from a requester, the email is looked up
    in LDAP to canonicalize the user info as well.
  • If the email address does NOT exist in the LDAP directory, go
    ahead and create an account anyway using the email address as the
    username.

You may just want to run with mod_auth_kerb and
RT::Extension::LDAPImport running periodically, cutting
RT::Authen::ExternalAuth completely out of the picture. This does
require users can auth with mod_auth_kerb unless you give them local RT
passwords.

The message I get in the RT log (via syslog) when a user logs in with
SSO seems to indicate that the user variable is not being set and
passed to the RT::Authen::ExternalAuth extension if I read the error
right. The odd thing to me, is that while the error says SSO is
failing, it most definitely is not. The user is successfully
logged in.
----- error from syslog —
Oct 14 16:41:25 rt RT: Attempting to use external auth service: LDAP_DIR1
Oct 14 16:41:25 rt RT: SSO Failed and no user to test with. Nexting
Oct 14 16:41:25 rt RT: Autohandler called ExternalAuth. Response: (0, No User)

Just a note: ExternalAuth’s SSO support is cookie based, not
Apache/mod_auth_* based. It is not trying to do the same SSO as the
core RT option.

Thomas

Hi,

From my last hacking on ExternalAuth I recall noticing that in some
case EA only lookups by Name and ignores any other mappings you may
have. I suspect that after SSO Name in RT doesn’t match mapped
attribute in LDAP and EA fails to find record to fetch information.

At the moment can not find that place in the code, but may be this is
root of the problem.On Mon, Oct 17, 2011 at 7:51 PM, Thomas Sibley trs@bestpractical.com wrote:

On 10/14/2011 08:44 PM, John Andersen wrote:

Hoping someone can point me to where I am going wrong. I have been
trolling the wiki, cpan, this list, and Google for the last couple of
days with no luck so far. Probably something apparent that I’m
missing…

I am after the following behavior:

  • A user inside our network and on a machine my company controls
    will be auto-logged in via SSO (mod_auth_kerb)
  • Upon successful SSO login, even if it’s a first time login, the
    user info in canonicalized from our LDAP dir (Active Directory)
  • If the user cannot use SSO, the login fails gracefully back to the
    form-based login built in to RT.
  • If the user successfully authenticates via
    RT::Authen::ExternalAuth the user info is again canonicalized even if
    it’s a first time login.
  • If an email is received from a requester, the email is looked up
    in LDAP to canonicalize the user info as well.
  • If the email address does NOT exist in the LDAP directory, go
    ahead and create an account anyway using the email address as the
    username.

You may just want to run with mod_auth_kerb and RT::Extension::LDAPImport
running periodically, cutting RT::Authen::ExternalAuth completely out of the
picture. This does require users can auth with mod_auth_kerb unless you
give them local RT passwords.

The message I get in the RT log (via syslog) when a user logs in with
SSO seems to indicate that the user variable is not being set and
passed to the RT::Authen::ExternalAuth extension if I read the error
right. The odd thing to me, is that while the error says SSO is
failing, it most definitely is not. The user is successfully
logged in.
----- error from syslog —
Oct 14 16:41:25 rt RT: Attempting to use external auth service: LDAP_DIR1
Oct 14 16:41:25 rt RT: SSO Failed and no user to test with. Nexting
Oct 14 16:41:25 rt RT: Autohandler called ExternalAuth. Response: (0, No
User)

Just a note: ExternalAuth’s SSO support is cookie based, not
Apache/mod_auth_* based. It is not trying to do the same SSO as the core RT
option.

Thomas

RT Training Sessions (http://bestpractical.com/services/training.html)

  • San Francisco, CA, USA October 18 & 19, 2011
  • Washington DC, USA October 31 & November 1, 2011
  • Barcelona, Spain November 28 & 29, 2011

Best regards, Ruslan.

Hoping someone can point me to where I am going wrong. I have been
trolling the wiki, cpan, this list, and Google for the last couple of
days with no luck so far. Probably something apparent that I’m
missing…

I am after the following behavior:

  • A user inside our network and on a machine my company controls
    will be auto-logged in via SSO (mod_auth_kerb)
  • Upon successful SSO login, even if it’s a first time login, the
    user info in canonicalized from our LDAP dir (Active Directory)
  • If the user cannot use SSO, the login fails gracefully back to the
    form-based login built in to RT.
  • If the user successfully authenticates via
    RT::Authen::ExternalAuth the user info is again canonicalized even if
    it’s a first time login.
  • If an email is received from a requester, the email is looked up
    in LDAP to canonicalize the user info as well.
  • If the email address does NOT exist in the LDAP directory, go
    ahead and create an account anyway using the email address as the
    username.

You may just want to run with mod_auth_kerb and RT::Extension::LDAPImport
running periodically, cutting RT::Authen::ExternalAuth completely out of the
picture. This does require users can auth with mod_auth_kerb unless you
give them local RT passwords.

Not a bad idea. That would actually work in my situation since
getting the users into the database is not time critical. Running
LDAPImport daily would probably work just fine.

I know it’s petty but I was kind of hoping for the form based login
from outside the network…

The message I get in the RT log (via syslog) when a user logs in with
SSO seems to indicate that the user variable is not being set and
passed to the RT::Authen::ExternalAuth extension if I read the error
right. The odd thing to me, is that while the error says SSO is
failing, it most definitely is not. The user is successfully
logged in.
----- error from syslog —
Oct 14 16:41:25 rt RT: Attempting to use external auth service: LDAP_DIR1
Oct 14 16:41:25 rt RT: SSO Failed and no user to test with. Nexting
Oct 14 16:41:25 rt RT: Autohandler called ExternalAuth. Response: (0, No
User)

Just a note: ExternalAuth’s SSO support is cookie based, not
Apache/mod_auth_* based. It is not trying to do the same SSO as the core RT
option.

Thomas

I did see that. For some reason, I had the idea that even using
$WebExternalAuth it would kick off CanonicalizeUserInfo() after
logging in, but that doesn’t seem to be happening. Or rather, it
does seem to be happening but it is running it without the username
key from mod_auth_kerberos. Thanks again for the info. I will
either try your suggestion above or go in another direction.

Thanks!

I know it’s petty but I was kind of hoping for the form based login
from outside the network…

Try playing around with the Satisfy Apache directive. It may be able to do
what you want.

-kevin