LDAP Authentication module does not place users under "Everyone"

Hi,

I’ve configured RT (3.8.5) to authenticate users using LDAP by adding the plugin RT::Authen::ExternalAuth.
My problem is that no user is under the global group “Everyone”, thus any permissions I give to the Everyone group does not get applied to all (or any) of the users.
The same thing goes with the “Unprivileged” group.
I have read somewhere that the authentication module does not place users under the right groups as it should.
Has anyone faced the same problem? Any suggestions how I can get around it?

Thanks in advance for the help
Nik

My RT_SiteConfig.pm configuration (only the part concerning the problem) :

Set(@Plugins,(qw(RT::Authen::ExternalAuth)));
Set($AutoCreate, {Privileged => 0});
Set($WebExternalAuth , 1);
Set($WebFallbackToInternalAuth , true);
Set($WebExternalAuto , 1);
Set($ExternalInfoPriority, [‘My_LDAP’]);
Set($ExternalServiceUsesSSLorTLS, 0);
Set($AutoCreateNonExternalUsers, 1);
Set($ExternalAuthPriority,[‘My_LDAP’]);

Set($ExternalSettings, {‘My_LDAP’ => {
‘type’ => ‘ldap’,
‘auth’ => 1,
‘info’ => 1,
‘server’ => ‘server_hostname’,
‘user’ => ‘defined’,
‘pass’ => ‘defined’,
‘base’ => ‘defined’,
‘filter’ => ‘(objectclass=Person)’,
‘d_filter’ => ‘(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))’,
‘tls’ => 0,
‘net_ldap_args’ => [ version => 3 ],
‘group’ => ‘’,
‘group_attr’ => ‘’,
‘attr_match_list’ => [ ‘Name’,
‘EmailAddress’,
‘RealName’,
‘WorkPhone’,
‘Address2’],
‘attr_map’ => { ‘Name’ => ‘sAMAccountName’,
‘EmailAddress’ => ‘mail’,
‘Organization’ => ‘physicalDeliveryOfficeName’,
‘RealName’ => ‘cn’,
‘ExternalAuthId’ => ‘sAMAccountName’,
‘Gecos’ => ‘sAMAccountName’,
‘WorkPhone’ => ‘telephoneNumber’,
‘Address1’ => ‘streetAddress’,
‘City’ => ‘l’,
‘State’ => ‘st’,
‘Zip’ => ‘postalCode’,
‘Country’ => ‘co’
}
}
}
);
1;

Hi,

I’ve configured RT (3.8.5) to authenticate users using LDAP by adding the plugin RT::Authen::ExternalAuth.
My problem is that no user is under the global group “Everyone”, thus any permissions I give to the Everyone group does not get applied to all (or any) of the users.
The same thing goes with the “Unprivileged” group.
I have read somewhere that the authentication module does not place users under the right groups as it should.

Where did you read this?

Has anyone faced the same problem? Any suggestions how I can get around it?

With your configuration, users will be placed in the Unprivileged
group and the Everyone group. That is managed by RT, not the module.

-kevin

Hi,

I’ve configured RT (3.8.5) to authenticate users using LDAP by adding the plugin RT::Authen::ExternalAuth.
My problem is that no user is under the global group “Everyone”, thus any permissions I give to the Everyone group does not get >applied to all (or any) of the users.
The same thing goes with the “Unprivileged” group.
I have read somewhere that the authentication module does not place users under the right groups as it should.

Where did you read this?

Not able to find the link at the moment but if I stumble upon it again I’ll let you know.

Has anyone faced the same problem? Any suggestions how I can get around it?

With your configuration, users will be placed in the Unprivileged
group and the Everyone group. That is managed by RT, not the module.

Yes, this was what I expected too but unfortunately this is not happening. It seems that my RT will only place users into the Privileged group when I give them the “Let this user be granted rights” in the Access Control of the user.

I tried creating a user manually to verify that the module is not responsible for this problem and indeed you’re right.
When created the user and loged in as him I still do not get the rights that I have defined for Everyone and Unprivileged.
The only options I have in the left side bar is to view the user’s open and closed tickets and create a new one.

Any idea what might be causing this problem or were I should start looking?

Thanks
-Nik

Unprivileged users get a different interface to that of privileged
users. What rights are you trying to give to ‘Everyone’?

[mailto:rt-devel-bounces@lists.bestpractical.com] On Behalf Of
n.chrysandreas@albourne.comSent: 23 November 2009 16:25
To: rt-devel@lists.bestpractical.com
Subject: Re: [Rt-devel] LDAP Authentication module does not place users
under “Everyone”

Hi,

I’ve configured RT (3.8.5) to authenticate users using LDAP by adding
the plugin RT::Authen::ExternalAuth.

My problem is that no user is under the global group “Everyone”, thus
any permissions I give to the Everyone group does not get >applied to
all (or any) of the users.

The same thing goes with the “Unprivileged” group.
I have read somewhere that the authentication module does not place
users under the right groups as it should.

Where did you read this?

Not able to find the link at the moment but if I stumble upon it again
I’ll let you know.

Has anyone faced the same problem? Any suggestions how I can get
around it?

With your configuration, users will be placed in the Unprivileged
group and the Everyone group. That is managed by RT, not the module.

Yes, this was what I expected too but unfortunately this is not
happening. It seems that my RT will only place users into the Privileged
group when I give them the “Let this user be granted rights” in the
Access Control of the user.

I tried creating a user manually to verify that the module is not
responsible for this problem and indeed you’re right.
When created the user and loged in as him I still do not get the rights
that I have defined for Everyone and Unprivileged.
The only options I have in the left side bar is to view the user’s open
and closed tickets and create a new one.

Any idea what might be causing this problem or were I should start
looking?

Thanks
-Nik

List info:
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
Spring Group plc is one of the UK’s leading recruitment and staffing services companies and is an active member of the Recruitment and Employment Confederation (REC). Our services encompass contract and permanent IT and technology staff, office and industrial staff, workforce management services and recruitment outsourcing (RO). Spring Technology is the winner of the 2008 Recruiter Awards for Excellence for ‘Best IT Recruitment Firm’ and engages the REC 2008 ‘IT Contractor of the Year’. To find out how Spring can help your organisation, please email enquiries@spring.com.
The contents of this e-mail and any attachment(s) are strictly confidential and are solely for the person(s) at the e-mail address(es) above. If you are not an addressee, you may not disclose, distribute, copy or use this e-mail, and we request that you send an e-mail to postman@spring.com and delete this e-mail. Spring Group plc accepts no legal liability for the contents of this e-mail including any errors, interception or interference, as internet communications are not secure. Whilst Spring Group plc and the sender have taken every precaution to prevent transmission of computer viruses, should this inadvertently occur we do not accept any liability. Spring Group plc, Hazlitt House, 4 Bouverie Street, London, EC4Y 8AX. Registered in England, company number: 590054. Web: http://www.spring.com

With your configuration, users will be placed in the Unprivileged
group and the Everyone group. That is managed by RT, not the module.

Yes, this was what I expected too but unfortunately this is not
happening. It seems that my RT will only place users into the
Privileged group when I give them the “Let this user be granted
rights” in the Access Control of the user.

Yes, users will only be Privileged if you check that box or if you set
Set($AutoCreate, {Privileged => 1}) in your config rather than Privileged => 0
which you showed us.

I tried creating a user manually to verify that the module is not responsible for this problem and indeed you’re right.
When created the user and loged in as him I still do not get the rights that I have defined for Everyone and Unprivileged.
The only options I have in the left side bar is to view the user’s open and closed tickets and create a new one.

Any idea what might be causing this problem or were I should start looking?

That is called the SelfService interface, which is where Unprivileged
users are directed when logging in to RT. You may want to read in the
wiki about the types of users
http://wiki.bestpractical.com/view/SelfService

-kevin

That is called the SelfService interface, which is where Unprivileged
users are directed when logging in to RT. You may want to read in the
wiki about the types of users
http://wiki.bestpractical.com/view/SelfService

Thanks! Didn’t know about the SelfService interface.
But this means that we are not able to grant unprivileged users any other rights that we would like (example : CreateOwnDashboard, CreateSavedSearch,CreateTicket,EditSavedSearches,ReplyToTicket,SeeOwnDashboard,ShowSavedSearches etc)

So if I got this right privileged users have the normal interface and the unprivileged users get the SelfService interface. However, whatever right I give to ‘Unprivileged’ group the SelfService interface will not change.

Thanks again for the help
-Nik

Hi everyone,

That is called the SelfService interface, which is where Unprivileged
users are directed when logging in to RT. You may want to read in the
wiki about the types of users
http://wiki.bestpractical.com/view/SelfService

Thanks! Didn’t know about the SelfService interface.
But this means that we are not able to grant unprivileged users any other rights that we would like (example : CreateOwnDashboard, >CreateSavedSearch,CreateTicket,EditSavedSearches,ReplyToTicket,SeeOwnDashboard,ShowSavedSearches etc)

So if I got this right privileged users have the normal interface and the unprivileged users get the SelfService interface.However, >whatever right I give to ‘Unprivileged’ group the SelfService interface will not change.

In order to get all users to see the normal RT interface I commented out the a few lines in /opt/rt3/share/html/autohandler
and “replaced” them with one :
#unless ( $session{‘CurrentUser’}->Privileged ) {

# if the user is trying to access a ticket, redirect them

if ( $m->request_comp->path =~ ‘^(/+)Ticket/Display.html’

&& $ARGS{‘id’} )

{

RT::Interface::Web::Redirect( RT->Config->Get(‘WebURL’) .“SelfService/Display.html?id=”.$ARGS{‘id’});

}

# otherwise, drop the user at the SelfService default page

elsif ( $m->base_comp->path !~ RT->Config->Get(‘SelfServiceRegex’) ) {

RT::Interface::Web::Redirect( RT->Config->Get(‘WebURL’) .“SelfService/” );

}

# if user is in SelfService dir let him do anything

else {

$m->comp( { base_comp => $m->request_comp }, $m->fetch_next, %ARGS);

}

#}
#else {

$m->comp( { base_comp => $m->request_comp }, $m->fetch_next, %ARGS);

#}

$m->comp( { base_comp => $m->request_comp }, $m->fetch_next, %ARGS);

Now any rights I grant to the Everyone and Unprivileged groups correspond correctly on the users interface.
Is there anything else I need to watch out for concerning this changed I made or should it work fine like this (it is at the moment and I haven’t noticed any strange functionality within RT).

Thanks
Nik

I think hacking the autohandler might not be the kosher way to accomplish
what you want. Even though you are authenticating against LDAP, RT is
"caching" some of the user’s attributes to form a unique identity for each
user which is used to manage rights. One of the “rights” or flags
associated with the user in the database is whether or not they are
privileged. I also think that there is a setting you can put in
RT_SiteConfig.pm that forces autocreated accounts to be privileged, which
would accomplish in the end what your hacked autohandler is doing, but
instead of the “privileged bit” being dynamically granted in a silent,
ninja-assassin like way, the right would be explicit in the database, and
you could turn it off for individual users…

-RobOn Tue, Nov 24, 2009 at 9:13 AM, n.chrysandreas@albourne.com wrote:

Hi everyone,

That is called the SelfService interface, which is where Unprivileged
users are directed when logging in to RT. You may want to read in the
wiki about the types of users
http://wiki.bestpractical.com/view/SelfService

Thanks! Didn’t know about the SelfService interface.
But this means that we are not able to grant unprivileged users any other
rights that we would like (example : CreateOwnDashboard,
CreateSavedSearch,CreateTicket,EditSavedSearches,ReplyToTicket,SeeOwnDashboard,ShowSavedSearches
etc)

So if I got this right privileged users have the normal interface and the
unprivileged users get the SelfService interface.However, >whatever right I
give to ‘Unprivileged’ group the SelfService interface will not change.

In order to get all users to see the normal RT interface I commented out
the a few lines in /opt/rt3/share/html/autohandler
and “replaced” them with one :
#unless ( $session{‘CurrentUser’}->Privileged ) {

if the user is trying to access a ticket, redirect them

if ( $m->request_comp->path =~ ‘^(/+)Ticket/Display.html’

&& $ARGS{‘id’} )

{

RT::Interface::Web::Redirect( RT->Config->Get(‘WebURL’)

.“SelfService/Display.html?id=”.$ARGS{‘id’});

}

otherwise, drop the user at the SelfService default page

elsif ( $m->base_comp->path !~ RT->Config->Get(‘SelfServiceRegex’) ) {

RT::Interface::Web::Redirect( RT->Config->Get(‘WebURL’)

.“SelfService/” );

}

if user is in SelfService dir let him do anything

else {

$m->comp( { base_comp => $m->request_comp }, $m->fetch_next,

%ARGS);

}

#}
#else {

$m->comp( { base_comp => $m->request_comp }, $m->fetch_next, %ARGS);

#}

$m->comp( { base_comp => $m->request_comp }, $m->fetch_next, %ARGS);

Now any rights I grant to the Everyone and Unprivileged groups correspond
correctly on the users interface.
Is there anything else I need to watch out for concerning this changed I
made or should it work fine like this (it is at the moment and I haven’t
noticed any strange functionality within RT).

Thanks
Nik


List info:
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

Hi Rob,

Thanks for the reply.
My problem is not having any autocreated account to be privileged. I am aware of the RT_SiteConfig.pm parameter and I wouldn’t want all users to be privileged.
My original problem was that the unprivileged users were directed to the SelfService interface that is limited and not ‘controlled’ by rights as the normal RT interface that the privileged users see.
I would like the unprivileged users to see the normal interface.
I have gave privileges to the desired users but for the rest (as they are quite many users and they are authenticated against LDAP) I would like them to see the normal RT interface and give them the desired right using the global group "Unprivileged"
I have gone through the RT_Config.pm but was not able to find a parameter to include in my RT_SiteConfig.pm that would redirect the unprivileged users to the normal interface.

Sorry for the confusion…I blame my English.

Thanks again
-Nik

That is called the SelfService interface, which is where Unprivileged
users are directed when logging in to RT. You may want to read in the
wiki about the types of users
http://wiki.bestpractical.com/view/SelfService

Thanks! Didn’t know about the SelfService interface.

But this means that we are not able to grant unprivileged users any
other rights that we would like (example : CreateOwnDashboard,
CreateSavedSearch,CreateTicket,EditSavedSearches,ReplyToTicket,SeeOwnDashboard,ShowSavedSearches
etc)

Dashboards are not available in the SelfService interface.

So if I got this right privileged users have the normal interface
and the unprivileged users get the SelfService interface. However,
whatever right I give to ‘Unprivileged’ group the SelfService
interface will not change.

There are definitely rights that affect the SelfService UI, such as
CreateTicket and ReplyToTicket, but the SelfService UI also limits
what searches are done for you

-kevin

My problem is not having any autocreated account to be privileged. I am aware of the RT_SiteConfig.pm parameter and I wouldn’t want all users to be privileged.

I think this is your problem. It isn’t clear why you don’t just want
all your LDAP users Privileged. You can put your admin users in groups and
grant those groups extra rights and leave the basic Privileged users
with relatively few rights.

-kevin