LDAP::UserSyncRolesDefinition Adds but doesn't remove

[taylorfarm]

LDAP::UserSyncRolesDefinition will add users to OTRS group based on AD group membership but when the user is removed from AD it will not remove the user from group membership.

I think this is a bug. The logs report no errors, just that the user is no longer in the group.

Thu May 22 13:06:12 2014][Notice][Kernel::System::Auth::Sync::LDAP::Sync] User: otrsagent not in GroupDN='CN=otrs_admins,OU=Groups,DC=NST,DC=local', Filter='(member=CN=otrs agent,OU=Test Customer,OU=OTRS,DC=NST,DC=local)

Code: Select all

$Self->{'AuthSyncModule::LDAP::UserSyncRolesDefinition'} = {
        # AD/LDAP group
			'CN=otrs_admins,OU=Groups,DC=NST,DC=local' => {
        # OTRS role
			'corp_admins' => 1,
		}

Where is the code that removes the user from the otrs group? Perhaps I can pin point the bug more concisely.

thanks,

[jojo]

you have to invalidade the user in OTRS when removed from AD. (you should deactivate him in AD, which is better for data consistency).

OTRS has no permanent connection to the LDAP/AD. Only if a user is login in, it will check if the user is allowed (via LDAP), with fallback from local database), update the local user if needed and also try to match the LDAP group memberships to the OTRS groups or roles. So no bug here, everything works as supposed and designed

[crythias]

The code is in /Kernel/System/Auth/Sync/LDAP.pm

All it does, essentially, is check if user is a member of appropriate LDAP lookup and GroupMemberAdd if it matches.

In *theory*, it could "Update", but you will want to be careful because there are legitimate possibilities where you don't want to bother with Active Directory just to add a single user to another (his own?) group within OTRS.

[taylorfarm]

So I tested several scenarios and I think I understand what is happening.

Basically what I wanted to understand is if a user changes roles in the organization can I just add him to a new role in AD and it update in OTRS... My initial test was not a good one.

Ex... OTRS Admin moves to Agent Role <they lose certain access>

For this scenario I just removed the user out of AD that made them OTRS Admins and was expecting them to lose all those rights. THAT DOES NOT WORK! --->

For a better test I created a No-Access Group (basically a blank role). I removed the OTRS Admins Role in AD and added the user to the No-Access Role in AD. After logging in it removed all access to the user in OTRS. IT WORKS!

Here is what I believe is happening. The code will not "update" the user role in OTRS unless there is a change to the "ADD" function of the script.

Function says .... since the user is not in any role in AD I will not run and continue to process like nothing has changed for the user. (when in fact it has changed)

IMHO. What it should say is....

Code: Select all

Check user access in AD
IF user is in linked group in config.pm THEN
      Add User to linked role
ELSEIF User is not in linked group in config.pm
     AND IF user is in linked roles in OTRS THEN
FOR EACH linked role in OTRS 
    Remove user
NEXT
ENDIF

I understand that some people may not want this to happen if they are running a hybrid role setup for example some people were manually added in OTRS and others were added to roles through AD. I would think that most people would not be doing this and at the very least it is bad practice.

So for now I believe this is a work around to what I wanted to do and I am wrong this is NOT a bug but would be a nice feature in upcoming releases if I can put a vote in to have it added.

Thanks for the replies as always forum is a big help.

[crythias]

I understand that some people may not want this to happen if they are running a hybrid role setup for example some people were manually added in OTRS and others were added to roles through AD. I would think that most people would not be doing this and at the very least it is bad practice.

I understand the mentality of "manage everything through ADUC" but on the other side, consider the real possibility that the person(s) managing OTRS may not actually have direct access to manage ADUC (delegation, privileges, not being a domain admin, etc.) If it takes managerial permissions and bureaucracy to effect a change in ADUC for something that can be handled and visualized in-place, in real time, in the app by the OTRS manager(s), it seems the path of least resistance to handle it there. I know that many other ldap-aware apps rely on ldap for authentication only but then use internal grouping for app-specific permissions.

Each environment is different, though.

[jranete]

In Config.pm first inactivate the role for the agent and then activate it.
See bellow an example:

Code: Select all

 $Self->{'AuthSyncModule::LDAP::UserSyncRolesDefinition'} = {
        'cn=otrs-agent,ou=Special Groups,dc=domain,dc=lan' => {
                    'Write Role' => 0,
        },
        'cn=otrs-agent,ou=Special Groups,dc=domain,dc=lan' => {
                    'Write Role' => 1,
        },
}

[crythias]

jnarete,

Welcome to OtterHub/OTRS forums. That's a great idea, except it seems to only clear for members of the group. Considering your example says, clear and set for the same group membership, it seems it would not be useful to remove someone who is not in the list.

Let's say Bob is in ADGroupA and OTRS RoleA.
Now Bob is no longer in ADGroupA
Your code says check all members of ADGroupA and clear their access, then reset their access. Bob isn't affected by this reset because he's not a member of ADGroupA.

To effectively do what you suggest would be to use a broader ADGroup to clear all access levels, then set the access levels based upon ADGroup membership.

[jranete]

Hi,

Meanwhile I did something quite similar.
The ideea is the agents needs to be members to ad group to be able to login.
This ad group it is also syncronized with an otrs role which has no access to any otrs group
When the roles are synchronized with
ad group this role will be first synchronized(set to 1) and then the other roles.
ex:

##############User Synchronization#####################
# Check if the user is allowed to auth in a posixGroup
# (e. g. user needs to be in a group xyz to use otrs)
$Self->{'AuthModule::LDAP::GroupDN'} = 'cn=otrs-agent,ou=Special Groups,dc=domain,dc=lan';
#$Self->{'AuthModule::LDAP::AccessAttr'} = 'memberUid';
$Self->{'AuthModule::LDAP::AccessAttr'} = 'member';
# for ldap posixGroups objectclass (just uid)
# $Self->{'AuthModule::LDAP::UserAttr'} = 'UID';
# for non ldap posixGroups objectclass (with full user dn)
$Self->{'AuthModule::LDAP::UserAttr'} = 'DN';

###############Roles Synchronization###################
$Self->{'AuthSyncModule::LDAP::UserSyncRolesDefinition'} = {
'cn=otrs-agent,ou=Special Groups,dc=domain,dc=lan' => {
'66.NoAccess' => 1,
# Info 66.NoAccess it's an otrs roles which does not have access to any otrs group. It needs to be created
},

'cn=otrs-agent-itsupport-ro,ou=Special Groups,dc=domain,dc=lan' => {
'1.0.IT Support-Read Role' => 1,
# Info 1.0.IT Support-Read Role it's an otrs roles which has access to '1.0.IT Support Group' otrs group for read only purposes It needs to be created
},

'cn=otrs-agent-itsupport-wr,ou=Special Groups,dc=domain,dc=lan' => {
'1.0.IT Support-Write Role' => 1,
# Info 1.0.IT Support-Write Role it's an otrs roles which has access to '1.0.IT Support Group' otrs group for full acess It needs to be created
},
#......etc
}