RT::Authen::ExternalAuth v0.06 Released - Includes3.8.x

Hello,
Testing 0.06 on RT 3.8.1, we are observing the same behaviour as Sean
when a new user tries to log in.

The error message is:
Can’t call method “SetDisabled” on an undefined value at
/opt/rt3pst/bin/…/lib/RT/User_Overlay.pm line 1087.

And the corresponding rows in the log are:
Nov 4 12:06:15 socrate RT: Transaction->Create couldn’t, as you didn’t
specify an object type and id (/opt/rt3pst/bin/…/lib/RT/Record.pm:1439)
Nov 4 12:06:15 socrate RT: Couldn’t get principal for not loaded object
(/opt/rt3pst/bin/…/lib/RT/User_Overlay.pm:1113)
Nov 4 12:06:15 socrate RT: RT::User::IsExternalPassword External Auth
OK ( AD_LDAP ): franzga0
(/opt/rt3pst/local/plugins/RT-Authen-ExternalAuth/lib/RT/User_Vendor.pm:
281)
Nov 4 12:06:15 socrate RT: Autocreated authenticated user franzga0 ( 52
)
(/opt/rt3pst/local/plugins/RT-Authen-ExternalAuth/html/Callbacks/Externa
lAuth/autohandler/Auth:64)
Nov 4 12:06:15 socrate RT: No principal for user #52
(/opt/rt3pst/bin/…/lib/RT/User_Overlay.pm:1120)

Nov 4 12:06:21 socrate RT: No principal for user #52
(/opt/rt3pst/bin/…/lib/RT/User_Overlay.pm:1120)
Nov 4 12:06:21 socrate RT: Group::HasMember was called with an argument
that isn’t an RT::Principal or id. It’s (undefined)
(/opt/rt3pst/bin/…/lib/RT/Group_Overlay.pm:1031)
Nov 4 12:06:21 socrate RT: No principal for user #52
(/opt/rt3pst/bin/…/lib/RT/User_Overlay.pm:1120)
Nov 4 12:06:21 socrate RT: Group::HasMember was called with an argument
that isn’t an RT::Principal or id. It’s (undefined)
(/opt/rt3pst/bin/…/lib/RT/Group_Overlay.pm:1031)

Thanks a lot,
Gabriele Franzini
ICT Applications Manager
Nerviano Medical Sciences SRL
PO Box 11 - Viale Pasteur 10
20014 Nerviano Italy
tel +39 0331581477
fax +39 0331581456

Sean McCreadie wrote:

Mike,

Thank you for looking at my problem. I disabled the log stack traces
as you suggested and attached the new log file. Now I can see that it

is indeed authenticating my test user “Joe User” with my AD. The
attached log file contains the results of first logging in
successfully as root and then as Joe User. When I try to login as the
AD user in the web UI I get the following error in the browser:

Can’t call method “SetDisabled” on an undefined value at
/opt/rt3/bin/…/lib/RT/User_Overlay.pm line 1087, line 514.

It’s a bit unusual. It seems that either the Autocreation is trying to
re-use a principleID that already exists for the user, or for some
reason it’s creating the principle as a group instead of a user.

Walking through the log:

[Mon Nov 3 14:22:48 2008] [debug]: RT::User::IsPassword External auth
SUCCEEDED
(/opt/rt3/local/plugins/RT-Authen-ExternalAuth/lib/RT/User_Vendor.pm:360
)

ExternalAuth checked your external source and is happy to allow access
as the user provided.
[Mon Nov 3 14:22:48 2008] [info]: Autocreated authenticated user juser
( 14 )
(/opt/rt3/local/plugins/RT-Authen-ExternalAuth/html/Callbacks/ExternalAu
th/autohandler/Auth:64)

Because no principle exists with that username, a user is being
autocreated by RT and it has been assigned the principleID (i.e.
userID/groupID) 14.
[Mon Nov 3 14:22:48 2008] [debug]: LDAP Search === Base:
dc=canyonpartners,dc=local == Filter:
(&(objectClass=*)(sAMAccountName=juser)) == Attrs:
l,cn,st,mail,sAMAccountName,co,streetAddress,postalCode,telephoneNumber,
sAMAccountName,physicalDeliveryOfficeName,sAMAccountName
(/opt/rt3/local/plugins/RT-Authen-ExternalAuth/lib/RT/User_Vendor.pm:853
)

Information about the user is being looked up in your specified info
database for importing into RT.
[Mon Nov 3 14:22:48 2008] [debug]: LDAP Search === Base:
dc=canyonpartners,dc=local == Filter:
(&(objectClass=*)(userAccountControl:1.2.840.113556.1.4.803:=2)(sAMAccou
ntName=juser))
== Attrs: uid
(/opt/rt3/local/plugins/RT-Authen-ExternalAuth/lib/RT/User_Vendor.pm:893
)

RT is now looking to see if any results are returned when combining a
search for the user specified and a search for disabled users. If a
result is returned, the user should be set disabled, if not the user
should be set enabled. In both cases, the method SetDisabled is used,
just with different params for enable or disable.
[Mon Nov 3 14:22:48 2008] [crit]: User #14 has principal of Group type
(/opt/rt3/bin/…/lib/RT/User_Overlay.pm:1123)

Critical failure. RT is trying to use the SetDisabled method to make
sure the user is enabled, but for some reason, the account with
principleID 14 is not a User object, it is a Group object, and you
cannot use RT::User::SetDisabled on a group, therefore RT doesn’t know
what to do and bombs out.

So, either Autocreate is re-using #14 that already exists as a group
where it shouldn’t, or Autocreate is creating a Group object not a User
object.

I would guess the former, but the details of Autocreate are beyond what
I’m familiar with.

Hope that helps.
Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371

Franzini, Gabriele [Nervianoms] wrote:

Hello,
Testing 0.06 on RT 3.8.1, we are observing the same behaviour as Sean
when a new user tries to log in.

Yes has also been reported as a bug on rt.perl.org. Working on it asap.

Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England