Hi all,
I now have RT and LDAP working (my previous post about LDAP auth I
resolved by wading through the code and finding that an account has to
already exist before LDAP auth will work).
However what I am finding is that people use their LDAP logins to use
the web page, but when they reply to a request via email RT adds them
another account under the name of their email address. So people are
ending up with two User records in the database.
Is this a problem ? Should I resolve it, or leave it ?
cheers
Dave
You need to put their e-mail address in the first account. Then
the second account won’t get created. RT doesn’t allow 2 users
to have the same e-mail address.
-ToddOn Thu, Dec 02, 2004 at 09:28:38AM +1100, Dave Harrison wrote:
Hi all,
I now have RT and LDAP working (my previous post about LDAP auth I
resolved by wading through the code and finding that an account has to
already exist before LDAP auth will work).
However what I am finding is that people use their LDAP logins to use
the web page, but when they reply to a request via email RT adds them
another account under the name of their email address. So people are
ending up with two User records in the database.
Is this a problem ? Should I resolve it, or leave it ?
cheers
Dave
The rt-users Archives
Be sure to check out the RT wiki at http://wiki.bestpractical.com
However what I am finding is that people use their LDAP logins to use
the web page, but when they reply to a request via email RT adds them
another account under the name of their email address. So people are
ending up with two User records in the database.
I would class this as a real problem. If you are using the LDAP code from;
http://wiki.bestpractical.com/index.cgi?LdapOverlay
then it should be creating accounts with the email address extracted
from the LDAP user record. Is that LDAP email address the same as the
one they using to email in?
That is the code that I’m using, however because I want RT to be
pre-primed for the users I’m knocking together a seeder script to pull
the info I need from the LDAP dir and using it to create User table
records for each person.
I guess what I needed clarified was that if a user has a given email
address defined for their account, if RT receives an email from that
address it recognises that it is from that user.
IE.
username:joe
email:joe@foo.com
If RT receives an email from ‘joe@foo.com’ it knows it should relate it
to the account ‘joe’, as opposed to creating another user entry for
‘joe@foo.com’ (in addition to the account ‘joe’)
Is this the case ?
Dave Harrison wrote:
That is the code that I’m using, however because I want RT to be
pre-primed for the users I’m knocking together a seeder script to pull
the info I need from the LDAP dir and using it to create User table
records for each person.
Why are you doing that? Are you using the $ParseNewMessageForTicketCcs
feature?
I guess what I needed clarified was that if a user has a given email
address defined for their account, if RT receives an email from that
address it recognises that it is from that user.
Yes. That is exactly what happens here. The only problem I have is
that I’m using the “$ParseNewMessageForTicketCcs” feature which doesn’t
query the LDAP server to map the email address to a userid for email Ccs
when a new email address appears. I haven’t had time to resolve that
one yet.
Carl.
That is the code that I’m using, however because I want RT to be
pre-primed for the users I’m knocking together a seeder script to pull
the info I need from the LDAP dir and using it to create User table
records for each person.
Why are you doing that? Are you using the $ParseNewMessageForTicketCcs
feature?
Because the alternative is to ask people to send an email to RT to
activate their accounts, and I can see that getting painful when it
doesn’t work (or they mess it up). The other thing is that we want to
be able to enable specific default priviliges for users without having
to add them into groups or give them ACLs by hand.
I guess what I needed clarified was that if a user has a given email
address defined for their account, if RT receives an email from that
address it recognises that it is from that user.
Yes. That is exactly what happens here. The only problem I have is
that I’m using the “$ParseNewMessageForTicketCcs” feature which doesn’t
query the LDAP server to map the email address to a userid for email Ccs
when a new email address appears. I haven’t had time to resolve that
one yet.
I don’t think that’s so much of a problem for the moment for us.
Probably useful in the long run though.
Hi Dave,
Dave Harrison wrote:
However what I am finding is that people use their LDAP logins to use
the web page, but when they reply to a request via email RT adds them
another account under the name of their email address. So people are
ending up with two User records in the database.
I would class this as a real problem. If you are using the LDAP code from;
http://wiki.bestpractical.com/index.cgi?LdapOverlay
then it should be creating accounts with the email address extracted
from the LDAP user record. Is that LDAP email address the same as the
one they using to email in?
Carl.
That is the code that I’m using, however because I want RT to be
pre-primed for the users I’m knocking together a seeder script to pull
the info I need from the LDAP dir and using it to create User table
records for each person.
Why are you doing that? Are you using the $ParseNewMessageForTicketCcs
feature?
Because the alternative is to ask people to send an email to RT to
activate their accounts, and I can see that getting painful when it
doesn’t work (or they mess it up). The other thing is that we want to
be able to enable specific default priviliges for users without having
to add them into groups or give them ACLs by hand.
Actually I just tried it, and even if I send an email to RT before my
account exists, no automatic account creation occurs, so I definitely
need to seed the account into the db. Once the account is there, the
LDAP auth works fine, but if the account doesn’t exist it doesn’t get
created.
So if the account doesn’t exist, sending an e-mail doesn’t create
an account, but if it does exist then sending an e-mail creates
a second account?On Thu, Dec 02, 2004 at 11:21:15AM +1100, Dave Harrison wrote:
Actually I just tried it, and even if I send an email to RT before my
account exists, no automatic account creation occurs, so I definitely
need to seed the account into the db. Once the account is there, the
LDAP auth works fine, but if the account doesn’t exist it doesn’t get
created.
The rt-users Archives
Be sure to check out the RT wiki at http://wiki.bestpractical.com
However what I am finding is that people use their LDAP logins to use
the web page, but when they reply to a request via email RT adds them
another account under the name of their email address. So people are
ending up with two User records in the database.
I’m not using LDAP but use mod_auth_pam to authenticate web access the same
way as unix system logins, checking first against the local passwd file then
against a windows domain controller. If a user sends email before I add
them to RT, it automatically creates an account with the full email address
as the login. I’ve
been manually removing the @domain part when I add privileges so the logins
will match the system. Is there a way to make this happen automatically for
email addresses in a few domains?
Les Mikesell
les@futuresource.com
I’m doing the same as you, Les, and have been wondering the same thing.On Dec 2, 2004, at 12:39 AM, Les Mikesell wrote:
However what I am finding is that people use their LDAP logins to use
the web page, but when they reply to a request via email RT adds them
another account under the name of their email address. So people are
ending up with two User records in the database.
I’m not using LDAP but use mod_auth_pam to authenticate web access the
same
way as unix system logins, checking first against the local passwd
file then
against a windows domain controller. If a user sends email before I
add
them to RT, it automatically creates an account with the full email
address
as the login. I’ve
been manually removing the @domain part when I add privileges so the
logins
will match the system. Is there a way to make this happen
automatically for
email addresses in a few domains?
Les Mikesell
les@futuresource.com
The rt-users Archives
Be sure to check out the RT wiki at http://wiki.bestpractical.com
smime.p7s (3.63 KB)
We use LDAP logins and we ran into the problem day one.
The workaround is to use a hacked version of the normal Mail
authentication module.
Ours takes the mail address and resolves it via repeated matching in NIS
mail.aliases. At the end you end up with a correct username. It should
be possible to do the same using aliases stored in a LDAP directory. It
also works for users who use multiple email addresses. For example:
User.Name@domain.com from his laptop and user@domain.com on his PDA.
Sorry for not posting the actual code, but it is rather ugly in its
current form (it runs ypmatch externally).
A.
Micah Cooper wrote: