Mailing List Archive: Request Tracker: Users

LDAP solution that works

Index | Next | Previous | View Threaded

tomas.olaj at usit

Aug 10, 2004, 5:16 AM

Post #1 of 7 (24921 views)
Permalink

LDAP solution that works

For our Scandinavian readers I have compiled a short install-note here for
our RT system:

<http://folk.uio.no/tomaso/jobb/rt-spec.html>

I have also got LDAP to work with Apache 2 (distributed with RHES30 which
hasn't the experimental mod_auth_ldap module compiled), and OpenLDAP using
(from ssl.conf) the following module:

# MOD_AUTH_LDAP by Muhammad A Muquit for Apache 2.x versjon 2.12.
#
http://muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap_apache2.html
#
#
AuthAuthoritative On
AuthName "Request Tracker (RT) Saksbehandlingsystemet ved UiO"
AuthType Basic
AuthOnBind On
# Sub_DNou=CIS,ou=People
LDAP_Persistent Off
# Bind_Tries 5
LDAP_Debug On
LDAP_Protocol_Version 3 (our server use TLS/certificate)
LDAP_Deref ALWAYS
LDAP_StartTLS On (our server use TLS/certificate)
# LDAP_CertDbDir path - only available through Netscape's SDK and SSL
configuration
LDAP_Server some-ldap-server.sub.domain
# LDAP_Server some-ldap-test-server.sub.domain - test LDAP server for UiO
LDAP_Port 389
# LDAP_Connect_Timeout 3 - Connect timeout in seconds - only available
using iPlanet SDK
# LDAP_Port 636 - If SSL is on, must specify the LDAP SSL port, usually
636
Base_DN "ou=Users,dc=sub,dc=domain"
# Base_DN "ou=People,dc=sub,dc=domain"
# Base_DN "o=Fox Chase Cancer Center,c=US"
# Bind_DN "uid=admin,o=Fox Chase Cancer Center,c=US"
# Bind_Pass "secret"
UID_Attr uid
# UID_Attr_Alt "mail"
# Group_Attr uniqueMember
SupportNestedGroups On
require valid-user
# require user muquit foo bar "john doe"
# require roomnumber "123 Center Building"
# require filter "(&(telephonenumber=1234)(roomnumber=123))"
# require group cn=rt-saksbehandler,ou=netgroups,dc=sub,dc=domain
# require group cn=rcs,ou=Groups

Our solution is as follows for authentication and authorisation:

1) LDAP for authentication. New users will be created automatically by RT
with their username. Of course, new users sending e-mail to RT will be
created by their e-mail address. That's not wanted, and we are
wondering how others deal with that.

2) In addition, we will not do a ldap dump (export/import) of userinfo
except password to the RT database (in our case a PostgeSQL database),
since we have potensially 10.000s of requestors. Instead we want to
build internally in RT userinfo on the run when we have
incoming requests. So, we need to create some form of a script that
searches through the RT database for username equals an e-mail adresss
or using something that triggers that script when we have incoming
requests to update the RT database with the correct userinfo. As said
before an incomming request creates an user with the e-mail address as
the username. We have our own service called "electronic post office"
which gives info about an user. So we don't need a dump from a LDAP
server or other user administrative system.

--
________________________________________________________________________
Tomas A. P. Olaj, email: tomas.olaj [at] usit, web: folk.uio.no/tomaso
University of Oslo / USIT (Center for Information Technology Services)
System- and Application Management / Applications Management Group
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com

carl at xena

Aug 10, 2004, 6:30 PM

Post #2 of 7 (24418 views)
Permalink

Re: LDAP solution that works [In reply to]

Hi Tomas,

Tomas A. P. Olaj wrote:

>1) LDAP for authentication. New users will be created automatically by RT
> with their username. Of course, new users sending e-mail to RT will be
> created by their e-mail address. That's not wanted, and we are
> wondering how others deal with that.
>
>
We use LDAP authentication here, but not through Apache. We use an LDAP
user authentication overlay which handles both logging in and email user
creation. There are links to it in the "Extensions" part of the
Contributions wiki page at

http://wiki.bestpractical.com/index.cgi?Contributions

It works a treat, except for autogenerating accounts for CCs on an
inbound email. We can live with that for the moment.

Carl.

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com

rpaskowitz at michener

Aug 11, 2004, 5:30 PM

Post #3 of 7 (24370 views)
Permalink

Re: LDAP solution that works [In reply to]

I am trying to use that overlay file, but am having some issues. Based on my understanding of that file, it just deals with the password authentication portion, and therefore requires the user to be pre-existing in the RT database.

We use Novell here and want to authenticate against the eDirectory LDAP server(something we do often). Ideally, we would want a user to be able to sign in with the novell name/password, have RT create a user with the given name, leave the password blank, and use the e-mail adress which can be grabbed from LDAP as well. A nice bonus would be the ability to have a user send an e-mail in, and if it is not associated with an account, perform an LDAP lookup for that address, and proceed with the same account creation described above.

This sounds roughly like what you said you have going, so I'd be interested to know what you have done, code or configuration wise aside from just that overlay file. Thanks,

Robert

>>> Carl Makin <carl [at] xena> 08/10/04 21:31 PM >>>
Hi Tomas,

Tomas A. P. Olaj wrote:

>1) LDAP for authentication. New users will be created automatically by RT
> with their username. Of course, new users sending e-mail to RT will be
> created by their e-mail address. That's not wanted, and we are
> wondering how others deal with that.
>
>
We use LDAP authentication here, but not through Apache. We use an LDAP
user authentication overlay which handles both logging in and email user
creation. There are links to it in the "Extensions" part of the
Contributions wiki page at

http://wiki.bestpractical.com/index.cgi?Contributions

It works a treat, except for autogenerating accounts for CCs on an
inbound email. We can live with that for the moment.

Carl.

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com

carl at xena

Aug 11, 2004, 9:31 PM

Post #4 of 7 (24372 views)
Permalink

Re: LDAP solution that works [In reply to]

Hi Robert,

Robert Paskowitz wrote:

>We use Novell here and want to authenticate against the eDirectory LDAP server(something we do often). Ideally, we would want a user to be able to sign in with the novell name/password, have RT create a user with the given name, leave the password blank, and use the e-mail adress which can be grabbed from LDAP as well. A nice bonus would be the ability to have a user send an e-mail in, and if it is not associated with an account, perform an LDAP lookup for that address, and proceed with the same account creation described above.
>
>
The system we have works the other way around. Users are automatically
created with data from the LDAP server by an inbound email. Once they
are created, then they can log in. We use the LDAPMail.pm file
(attached) in the <site>/rt3/lib/RT/Interface/Email/Auth directory to do
the LDAP based auto user creation. I got that off this list, but I
can't remember who from. :( LDAPMail.pm associated with
<site>/rt3/local/lib/RT/User_Local.pm (attached) and this snippet in the
RT_SiteConfig.pm file do it all for us.

# LDAP Authentication
$LDAPExternalAuth = 1;
$LdapServer="your.directory.server";
$LdapUser="";
$LdapPass="";
$LdapBase="dc=your,dc=directory,dc=serverbase";
$LdapUidAttr="uid";
$LdapFilter="(objectclass=inetOrgPerson)";

# LDAP entry from mail.
@RT::MailPlugins = (
"Auth::LDAPMail",
"Auth::MailFrom"
);

At some point I hope to find the time to dive in and make the
"ParseNewMessageForTicketCcs" function use LDAP data as well.

Unfortunately this might all go out the window here as my management are
keen on using a single "Service Desk" based system across the whole
organisation, and the peope in charge of that are only interested in
commercial packages. <sigh>

Hope this helps.
Carl.

Attachments:

LDAPMail.pm (6.46 KB)

User_Local.pm (3.41 KB)

rpaskowitz at michener

Aug 12, 2004, 6:38 AM

Post #5 of 7 (24405 views)
Permalink

Re: LDAP solution that works [In reply to]

Thanks for the file, I knew there was some sort of a missing link. Unfortunatly our LDAP idea here may not take off because of some complexities. Our users are stored in all levels of the tree, so a fairly bruteforce recursive check is needed, which is time consuming, wasteful, and doesn't always seem to work. Some of our other software uses IMAP authentication, so I am currentlly looking into modifying the LDAP portions to do IMAP. We save having to do the lookups for the dn, which is a big plus.

Whatever I end up with will be posted back to the list. Even if we stick with LDAP, the recursive search may be useful to some.

>>> Carl Makin <carl [at] xena> 08/12/04 00:32 AM >>>
Hi Robert,

Robert Paskowitz wrote:

>We use Novell here and want to authenticate against the eDirectory LDAP server(something we do often). Ideally, we would want a user to be able to sign in with the novell name/password, have RT create a user with the given name, leave the password blank, and use the e-mail adress which can be grabbed from LDAP as well. A nice bonus would be the ability to have a user send an e-mail in, and if it is not associated with an account, perform an LDAP lookup for that address, and proceed with the same account creation described above.
>
>
The system we have works the other way around. Users are automatically
created with data from the LDAP server by an inbound email. Once they
are created, then they can log in. We use the LDAPMail.pm file
(attached) in the <site>/rt3/lib/RT/Interface/Email/Auth directory to do
the LDAP based auto user creation. I got that off this list, but I
can't remember who from. :( LDAPMail.pm associated with
<site>/rt3/local/lib/RT/User_Local.pm (attached) and this snippet in the
RT_SiteConfig.pm file do it all for us.

# LDAP Authentication
$LDAPExternalAuth = 1;
$LdapServer="your.directory.server";
$LdapUser="";
$LdapPass="";
$LdapBase="dc=your,dc=directory,dc=serverbase";
$LdapUidAttr="uid";
$LdapFilter="(objectclass=inetOrgPerson)";

# LDAP entry from mail.
@RT::MailPlugins = (
"Auth::LDAPMail",
"Auth::MailFrom"
);

At some point I hope to find the time to dive in and make the
"ParseNewMessageForTicketCcs" function use LDAP data as well.

Unfortunately this might all go out the window here as my management are
keen on using a single "Service Desk" based system across the whole
organisation, and the peope in charge of that are only interested in
commercial packages. <sigh>

Hope this helps.
Carl.

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com

carl at xena

Aug 16, 2004, 4:47 PM

Post #6 of 7 (24427 views)
Permalink

Re: LDAP solution that works [In reply to]

Hi Robert,
Sorry for taking so long to reply.

Robert Paskowitz wrote:

>take off because of some complexities. Our users are stored in all levels of the tree, so a fairly bruteforce recursive check is needed, which is time consuming, wasteful, and doesn't always seem to work. Some of our
>
How about bringing up another LDAP server with a more standard schema
and populating it from the first at regular intervals. Our primary LDAP
server is actually populated from several different sources, some of
them other LDAP servers with weird schemas (The PABX management server
for instance) and NT/Active Directory groups.

You could also then get rid of the IMAP authentication as well.

Carl.

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com

rpaskowitz at michener

Aug 17, 2004, 5:39 AM

Post #7 of 7 (24407 views)
Permalink

Re: LDAP solution that works [In reply to]

The need for a second LDAP server just doesn't exist within the building. We actually do have multiple LDAP servers running, but each is a mirror, as they are all brought up by eDirectory on NetWare machines.

I managed to implement the IMAP authentication, and it was dirt simple. I used the existing code for the LDAP authentication, and just popped in a few IMAP lines.

Bringing up a second LDAP server would simplify the authentication, (no recursive seraching for the context), which is already perfected (as much as can be) for our other uses. Unfortunatly even if we implemented the second LDAP server, we would still need the IMAP service up to authenticate fully external entities that cannot authenticate against eDirectory.

I plan to clean up my code a bit, and post the IMAP authentication, hopefully some other people may find it useful.

Robert

>>> Carl Makin <carl [at] xena> 08/16/04 19:48 PM >>>
Hi Robert,
Sorry for taking so long to reply.

Robert Paskowitz wrote:

>take off because of some complexities. Our users are stored in all levels of the tree, so a fairly bruteforce recursive check is needed, which is time consuming, wasteful, and doesn't always seem to work. Some of our
>
How about bringing up another LDAP server with a more standard schema
and populating it from the first at regular intervals. Our primary LDAP
server is actually populated from several different sources, some of
them other LDAP servers with weird schemas (The PABX management server
for instance) and NT/Active Directory groups.

You could also then get rid of the IMAP authentication as well.

Carl.

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads