Re: [rt-users] REST API for Assets

[Josh Tackitt]

Hi Bart,

Unfortunately there is no REST API for Assets.  I've heard rumors that
maybe they're working on it but pretty sure I've not seen anything official.

Is anyone out there interested in combining funds to pay for the
development of this much needed feature?  I'm sure we could convince
BestPractical to roll it into 'core' so that everyone would benefit.

Best,
Josh

On Wed, Nov 23, 2016 at 3:26 PM, Bart Bunting 
wrote:

> Hi,
>
> Is there a REST API for assets in RT?
>
> I can't find any documentation for it.
>
> Can anyone shed any light on if it exists or is in the works?
>
>
> Kind regards
> Bart
> --
>
> Bart Bunting - URSYS
> PH: 02 87452811
> Mbl: 0409560005
> -
> RT 4.4 and RTIR training sessions, and a new workshop day!
> https://bestpractical.com/training
> * Los Angeles - January 9-11 2017
>



-- 
Reed College
Computer Hardware Services
ETC 114
503-788-6661
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Los Angeles - January 9-11 2017

Re: [rt-users] RT 4.4.1 - ExternalAuth intermittently failing

[Shawn M Moore]

Hi Michel, Mike,

> On Dec 2, 2016, at 14:02, Michel Daoust  wrote:
> On successful binds, the username/password combination was correct, as 
> specified in our config. We waited for the LDAP bind error to happen and when 
> it did, we found this in the log:
> ldap_user: ldap_user_account, ldap_pass:Password not printed. (literal 
> Password not Printed). This is whats causing the bind to fail. For some 
> reason, RT is sending the masked password string (used in the web ui when 
> looking at system configs), which of course isn't the right password for the 
> bind account.

Thank you for this detailed bug report. I think I've identified the issue; it's 
indeed what you're describing. When you visit the system configuration page, RT 
accidentally overwrites the LDAP password in memory as part of obfuscating it. 
The fix looks straightforward; we'll get it into RT 4.4.2.

Best,
Shawn
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Los Angeles - January 9-11 2017

Re: [rt-users] how to supply db credentials to rt-email-dashboards?

[Landon Stewart]

As far as I know the ~user/.rtrc file is good for both rt-crontool and the rt 
utility itself. I've cc'd the list in case anyone has any more info or 
corrections.

--
Landon Stewart
Lead Analyst - Abuse and Security Management
INTERNAP ®
 lstew...@internap.com
 www.internap.com

On Nov 28, 2016, at 6:47 AM, Alex Hall 
> wrote:

Thank you, this works perfectly. What else is this 'rtrc' file good for, if 
anything? Or is it only for the scripts in [rtDir]/sbin to use for database 
connections?

On Fri, Nov 25, 2016 at 7:31 PM, Landon Stewart 
> wrote:
On Nov 25, 2016, at 2:08 PM, Alex Hall 
> wrote:

Hi list,
I'm trying to run /opt/rt4/sbin/rt-email-dashboards, but am getting an error 
that the database credentials are not correct. They aren't, but why? If they 
get picked up from the configuration, they should be correct, since RT itself 
is running just fine. If they aren't gotten from the configuration files, where 
do they come from and how can I supply them? The tool's help text didn't list 
any DB settings as possible flags. Thanks.

In the homedir of the user that runs the rt-email-dashboards create a file 
called '.rtrc'.

That file should contain:
server 
user root
passwd 

Example:
# cat ~root/.rtrc
server http://localhost/rt
user root
passwd ohsupaihai7moR1

--
Landon Stewart
Lead Analyst - Abuse and Security Management
INTERNAP ®
 lstew...@internap.com
 www.internap.com




--
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Los Angeles - January 9-11 2017

Re: [rt-users] RT 4.4.1 - ExternalAuth intermittently failing

[Michel Daoust]

Hi,

My colleague Mike Johnson originally sent this request. I'd like to follow
up on our investigation.

We have figured out the why, but we still don't understand what is causing
this issue. Details below.

While debugging, we captured packets and received error code 52e from the
AD server (LDAP equivalent of error 49 RT was throwing). This indicates
that the login username is correct, but the password is incorrect. This is
what threw us off since it didn't make sense. The config user/pass is
correct and the account would work 90% of the time and we would get this
error seemingly at random.

So we decided to edit the RT source code where the LDAP bind happens
(/opt/rt4/lib/RT/Authen/ExternalAuth/LDAP.pm:634) and added lines to log
the $ldap_user and $ldap_pass variables to see what RT was trying to bind
with.

On successful binds, the username/password combination was correct, as
specified in our config. We waited for the LDAP bind error to happen and
when it did, we found this in the log:
ldap_user: ldap_user_account, ldap_pass:Password not printed. (literal
Password not Printed). This is whats causing the bind to fail. For some
reason, RT is sending the masked password string (used in the web ui when
looking at system configs), which of course isn't the right password for
the bind account.

As a temporary bandaid solution, we've hardcoded the LDAP bind credentials
in the source code. Since doing so, we haven't seen the error happen again.
So at this point, this seems like a bug in RT? Has anyone else experienced
something similar?

Thanks,

*Michel Daoust, BSc.*
Software Developer / Systems Analyst, Information Technology
Northern Ontario School of Medicine
935 Ramsey Lake Road
Sudbury, ON. P3E 2C6

Phone: 705-662-7193
Email: midao...@nosm.ca


On Wed, Nov 23, 2016 at 3:21 PM, Mike Johnson  wrote:

> Hi,
>
> It happened again today. Our AD admin didn't see anything unusual in the
> logs. I'm getting him to see if successful bind attempts show up anywhere,
> and if so... if RT is actually successful and the error message is just not
> appropriate(ie something else behind the scenes is going on and it's just
> reported as a failed bind).
>
> Anyone have any thoughts on this?
>
> We have multiple other LDAP authenticated, and Windows authenticated
> systems on campus using this AD service(different usernames) and we haven't
> had reports of any of these failing.
>
> The things that have changed from what it was working:
> - OS: CentOS 7.2.15.11
> - perl 5.16.3
> - RT version 4.4.1
>
> I can't recall the previous OS version or perl version, but it was at
> least on Redhat 4 or 5, and RT was 3.8.X using ExternalAuth extension(on
> 3.8 it wasn't rolled into baseline yet).
>
> Any thoughts are appreciated!
> Mike.
>
> On Tue, Nov 22, 2016 at 4:40 PM, Kenneth Marshall  wrote:
>
>> On Tue, Nov 22, 2016 at 04:13:46PM -0500, Mike Johnson wrote:
>> > We just went live with RT 4.4.1 and it seems that LDAP authentication is
>> > failing.
>> >
>> > It has now died 2 days in a row, at approximately the same time.
>> >
>> > The RT log is showing the following error:
>> > 2819] [Mon Nov 21 21:10:28 2016] [critical]:
>> > RT::Authen::ExternalAuth::LDAP::_GetBoundLdapObj Can't bind:
>> > LDAP_INVALID_CREDENTIALS 49
>> > (/opt/rt4/sbin/../lib/RT/Authen/ExternalAuth/LDAP.pm:678)
>> >
>> > This seems like a generic LDAP error, and it's not pointing us to a
>> > specific issue.
>> >
>> > The user that we are binding with is a user that was in-use on our RT
>> 3.8.X
>> > environment that hadn't had an issue in years (3?).
>> >
>> > Restarting apache resolves the immediate issue, but clearly there is
>> > something else going on that we should be able to fix permanently.
>> Anyone
>> > have any ideas on where to look?
>> >
>> > This didn't come up in our testing, but I don't believe we had the
>> volume
>> > of credential testing that we do in prod.
>> >
>> > Any help would be great!
>> >
>> > P.S. The LDAP server is a Microsoft Active Directory server. This same
>> > server was being used for ExternalAuth extension in 3.8.
>> >
>> > Mike.
>>
>> Hi Mike,
>>
>> You probably will need to check your AD logs as well. We have seen issues
>> with AD authentication when an account is locked out by a bad password
>> login attempt. Since it is about the same time of day, maybe something
>> else is trying to login with those credentials and causing it to lock.
>>
>> Regards,
>> Ken
>>
>
>
>
> --
> Mike Johnson
> Datatel Programmer/Analyst
> Northern Ontario School of Medicine
> 955 Oliver Road
> Thunder Bay, ON   P7B 5E1
> Phone: (807) 766-7331
> Email: mike.john...@nosm.ca
>
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Los Angeles - January 9-11 2017