Error accesing Management Portal: Prevent "User <username>" from logging in because it is not a member of the administrator group

[javierms]

Hi all!

After upgrading to 2.7, we are getting this error trying to log in the management portal:

Prevent "User <username>" from logging in because it is not a member of the administrator group

Is not happening with all users, that's the weird thing. Anyone has been through this issue too?

[JHT_Seattle]

Maybe try changing the group that can authenticate as Admins in App Volumes, then try changing it back?  Sounds like something in the DB may have gotten a little confused.  When I updated I was getting a message that the logged in user wouldn't be able to authenticate because it wasn't in the security group that I had configured AV to use (it was).  I changed it and changed it back and the message went away.

[javierms]

The thing is, some users of that admin group actually have access to the portal while others not...also there's not nested groups, AD token size issues or whatever...

[ARuvVD11]

I am getting the same thing.

[2015-05-27 20:06:20 UTC] P3396R75  INFO	RADIR: Connection to AD bla.bla.bla.net succeeded - Took 109ms
[2015-05-27 20:06:20 UTC] P3396R75  INFO	Cvo: Processing login for "OU\admin-scott" using "bla.bla.bla.net"
[2015-05-27 20:06:20 UTC] P3396R75  INFO	Manager: Existing "User <OU\admin-scott>" logged in
[2015-05-27 20:06:20 UTC] P3396R75  WARN	Manager: Prevented "User <OU\admin-scott>" from logging in because it is not a member of the administrator group

[2015-05-27 20:06:20 UTC] P3396R75  INFO   Rendered login/login.html.erb (0.0ms)

[2015-05-27 20:06:20 UTC] P3396R75  INFO Completed 200 OK in 281.1ms (Views: 0.0ms | ActiveRecord: 15.6ms)

[2015-05-27 20:06:20 UTC] P3396R75  INFO

Just for giggles I added another account into the security group for the app volumes admins, WORKS FINE. This recently came up after changing the AD settings, so I am going with the DB for app volumes is borked.

Anyone know how to manually remove a user?

[JHT_Seattle]

There might be another reason one user can't log on but another could:  Active Directory permissions for the account you have configured with App Volumes to do your LDAP lookups.  We recently saw this issue because our AD account did not have permissions to enumerate groups for some user accounts, leading to missing stacks at logon.  It sounds like it would affect logins to the Manager as well if the proper groups could not be enumerated.

[RobBeekmans]

Hi,

I got the same message when trying to logon to the console.

Installed and configured just fine, walked away for a minute and when I came back I had to logon to the console again.. which failed with this error exactly.

AppVolumes is installed in the top domain, the administration group is in a subdomain, which during configuration was enumerated just fine.

Freaky stuff it that it all worked fine and really a minute later I'm locked out...

off to some more debugging

Greetings

Rob

[UCD]

Basically the same situation here, but the other way around. I've found a workaround. If I join the lowest subdomain it wont autosearch upwards (WTF.) BUT if I list the higher domains specifically in the "trust domains" option in the AD configuration, it WILL search the upper domains. :smileygrin:

Of course I have other trusts attached to the higher domain, haven’t tested those yet. fully expect it that to NOT work.

[javierms]

UCD, actually it does work! If you add that domain of your forest in the "Trusted Domains" textbox...that's going to work.

[RobBeekmans]

hi,

I found what I did wrong... I got multiple subdomains and for a reason unknown I selected the wrong subdomain.

Only after I checked the database I noticed that I added a wrong group for a wrong domain.

changing the entry in the database fixed it instantly, so the error was me.