[rt-users] Please help with RT::Authen::ExternalAuth with nested LDAP/AD groups

[Landon Stewart]

Hello,

I have a working mod_authnz_ldap configuration for apache 2.4 (on a virtualhost 
on the same server) but I cannot seem to convert the configuration to a valid 
RT::Authen::ExternalAuth::LDAP configuration.  At one point I could see in 
var/log/rt.log that it was at least checking the nested groups for membership 
but the filter didn't look quite right.  I have since changed that 
configuration and it seems to stall for a minute and then fail.  It gets my 
real name from the AD service but then cannot match the sub/nested group filter 
I think?

The apache configuration that works is:

LogLevel debug
AuthName "Password protected. Enter your AD username and password."
AuthType Basic
AuthBasicProvider ldap
AuthLDAPURL 
"ldap://ldap.server.hostname/OU=iweb,DC=corp,DC=iweb,DC=com?sAMAccountName?sub?(objectClass=*)"
AuthLDAPGroupAttribute member
AuthLDAPGroupAttributeIsDN on
AuthLDAPBindDN "ldapbinduserstring"
AuthLDAPBindPassword ldapbindpass
Require ldap-filter 
memberOf:1.2.840.113556.1.4.1941:=CN=RTIR_WEB_SC_ACCESS,OU=Groupes,OU=iWeb,DC=corp,DC=iweb,DC=com



So far I've got this in RT_SiteConfig.pm for RT:
...snipped...
Set($ExternalSettings, {
'My_LDAP' => {
'type' => 'ldap',
'server' => 'corp.iweb.com',
'user' => 'ldapbinduserstring',
'pass' => 'ldapbindpass',
'base' => 'OU=iweb,DC=corp,DC=iweb,DC=com',
'filter' => '(objectClass=*)',
'd_filter' => 'UserAccountControl:1.2.840.113556.1.4.803:=2',
'group' => 'RTIR_WEB_SC_ACCESS',
'group_scope' => 'sub',
'group_attr' => 
'memberOf:1.2.840.113556.1.4.1941:=CN=RTIR_WEB_SC_ACCESS',
'group_attr_value' => 'OU=Groupes,OU=iWeb,DC=corp,DC=iweb,DC=com',
'tls' => 0,
'attr_match_list' => [
'Name',
'EmailAddress',
],
'attr_map' => {
'Name' => 'sAMAccountName',
'EmailAddress' => 'mail',
'Organization' => 'physicalDeliveryOfficeName',
'RealName' => 'cn',
'ExternalAuthId' => 'sAMAccountName',
'Gecos' => 'sAMAccountName',
},
},
} );
...snipped...
Plugin('RT::IR', 'RT::Authen::ExternalAuth');

The log entries with the above configuration are:
[28280] [Thu Jul 14 19:12:14 2016] [debug]: Attempting to use external auth 
service: My_LDAP 
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:424)
[28280] [Thu Jul 14 19:12:14 2016] [debug]: Calling UserExists with $username 
(lstewart) and $service (My_LDAP) 
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:465)
[28280] [Thu Jul 14 19:12:14 2016] [debug]: UserExists params:
username: lstewart , service: My_LDAP 
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:439)
[28280] [Thu Jul 14 19:12:14 2016] [debug]: LDAP Search ===  Base: 
OU=iweb,DC=corp,DC=iweb,DC=com == Filter: 
(&(objectClass=*)(sAMAccountName=lstewart)) == Attrs: 
sAMAccountName,physicalDeliveryOfficeName,mail,cn,sAMAccountName,sAMAccountName 
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:469)
[28280] [Thu Jul 14 19:12:14 2016] [debug]: Password validation required for 
service - Executing... 
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:517)
[28280] [Thu Jul 14 19:12:14 2016] [debug]: Trying external auth service: 
My_LDAP 
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:153)
[28280] [Thu Jul 14 19:14:14 2016] [debug]: LDAP Search ===  Base: 
OU=iweb,DC=corp,DC=iweb,DC=com == Filter: 
(&(sAMAccountName=lstewart)(objectClass=*)) == Attrs: 
dn,OU=Groupes,OU=iWeb,DC=corp,DC=iweb,DC=com 
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:186)
[28280] [Thu Jul 14 19:14:14 2016] [debug]: Found LDAP DN: CN=Landon 
Stewart,OU=Utilisateurs,OU=iWeb,DC=corp,DC=iweb,DC=com 
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:220)
[28280] [Thu Jul 14 19:14:15 2016] [debug]: Attribute 
'OU=Groupes,OU=iWeb,DC=corp,DC=iweb,DC=com' has no value; falling back to 
'CN=Landon Stewart,OU=Utilisateurs,OU=iWeb,DC=corp,DC=iweb,DC=com' 
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:249)
[28280] [Thu Jul 14 19:14:15 2016] [debug]: LDAP Search ===  Base: 
RTIR_WEB_SC_ACCESS == Scope: sub == Filter: 
(memberOf:1.2.840.113556.1.4.1941:=CN=RTIR_WEB_SC_ACCESS=CN=Landon 
Stewart,OU=Utilisateurs,OU=iWeb,DC=corp,DC=iweb,DC=com) == Attrs: dn 
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:256)
[28280] [Thu Jul 14 19:14:15 2016] [critical]: Search for 
(memberOf:1.2.840.113556.1.4.1941:=CN=RTIR_WEB_SC_ACCESS=CN=Landon 
Stewart,OU=Utilisateurs,OU=iWeb,DC=corp,DC=iweb,DC=com) failed: 
LDAP_INVALID_DN_SYNTAX 34 
(/opt/rt4/local/plugins/RT-Authen-Extern

Re: [rt-users] [rt-announce] RT Wiki Move Complete

[Nilesh]

This is great news. 
Please enable URL rewriting so that people can access rt-
wiki.bestpractical.com/FOO and view the wiki page. Searching isn't not that user
friendly especially if you know the topic name.

-- 
Nilesh

On Thu, 2016-07-14 at 10:14 -0400, Jim Brandt wrote:
> Hello RT Users,
> 
> As mentioned previously [1], we've been working on moving the RT 
> community wiki from Wikia (The Home of Fandom) to a stand-alone 
> Mediawiki instance. After some wiki-spam fighting, the new site seems to 
> be running smoothly.
> 
> As of yesterday (Wednesday, July 14) the Wikia site has been closed. The 
> official RT wiki is now at https://rt-wiki.bestpractical.com. The URL 
> https://wiki.bestpractical.com should also lead you there, although 
> there may still be some caching of the old address.
> 
> Please update your links if you have any pointing directly to the old 
> Wikia address.
> 
> We hope you enjoy the new ad-free wiki. Feel free to create a new 
> account, help us clean up some content, or add some helpful new RT 
> information.
> 
> Thanks,
> Best Practical
> 
> [1] 
> http://lists.bestpractical.com/pipermail/rt-announce/2016-June/000286.html
> ___
> rt-announce mailing list
> rt-annou...@lists.bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce
> -
> RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
> * Los Angeles - September, 2016
-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016

[rt-users] [rt-announce] RT Wiki Move Complete

[Jim Brandt]

Hello RT Users,

As mentioned previously [1], we've been working on moving the RT 
community wiki from Wikia (The Home of Fandom) to a stand-alone 
Mediawiki instance. After some wiki-spam fighting, the new site seems to 
be running smoothly.


As of yesterday (Wednesday, July 14) the Wikia site has been closed. The 
official RT wiki is now at https://rt-wiki.bestpractical.com. The URL 
https://wiki.bestpractical.com should also lead you there, although 
there may still be some caching of the old address.


Please update your links if you have any pointing directly to the old 
Wikia address.


We hope you enjoy the new ad-free wiki. Feel free to create a new 
account, help us clean up some content, or add some helpful new RT 
information.


Thanks,
Best Practical

[1] 
http://lists.bestpractical.com/pipermail/rt-announce/2016-June/000286.html

___
rt-announce mailing list
rt-annou...@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce
-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016

[rt-users] API call to get "Created" value of history replies of all tickets

[Andrii Iudin]

Hello All,

We are using RT 4.2.12 through API to allow the communication between 
the users of our deposition system and the reviewers of those 
depositions. We have a single RT user which is used by our deposition 
system to create and manage tickets for all depositors. Each deposition 
has an ID associated with it and this ID is stored as a custom field for 
each ticket. We have a page that displays the list of all depositions. 
If there is a new message available, then a notification is displayed 
near the deposition in this list. Whether the message is new or not is 
determined based on the "Created" value of the last reply to the ticket. 
This value is compared with the corresponding value in the database and 
each time the ticket history is opened through our deposition system the 
database's value is updated.


The problem lies in getting the "Created" value of the last reply for 
each deposition. This is done through a query

/REST/1.0/ticket//history?format=l

However, since this has to be done for all the depositions' unresolved 
tickets, the loading of the page with the deposition list can take a 
long time (each API call is about 200 ms or more). Please could you tell 
if there is a query available to get the history for all the tickets in 
the queue in one go? We can then parse the result to obtain the 
necessary last reply times. Or is there a better way available to see 
the time of the last reply to the ticket, the email and whether it is a 
comment or not?


Best regards,
Andrii
-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016