RE: [otrs] Limit Agent user registration

Our ADS/LDAP tree is organized using location: ou=Moscow, cn=user1, cn=user2, .... ou=Stavanger, cn=user1, cn=user2, ... We will have at least one OTRS "agent" per location, with the rest of the users being "customers". Moving admin users to another common baseDN is not an option either due to group policies etc. If I could only find the code which allows this agent registration, I could comment it out and the problem would be solved... Thomas
-----Original Message----- From: Robert Kehl [mailto:robert.kehl@otrs.de] Sent: Thursday, March 25, 2004 3:31 PM To: User questions and discussions about OTRS. Subject: Re: [otrs] Limit Agent user registration
On Thursday, March 25, 2004 2:43 PM Thomas Nilsen
wrote: Auto registration might be the wrong term. But since we have set up AD as the main authentication source for both customers and agents, and using the same base dn, customers can then log on as agents as well by just entering their usernames/passwords twice. The first time they get the message: "Useraccount activated, retry.". Then they can log on to the agent front-end... They won't see any queues or anything, but we still don't want them to be able to register as agents.
Ah, I see. This is the synchronization from LDAP to DB. Kinda auto-regging indeed, yes.
How to prevent this? Put your customers in their own group - it's that simple. Do not use the same baseDN. Example: Assuming, your Agents are here: ou=People,ou=Headquarter,dc=example,dc=com Your Customers are here (or at least should be) ou=Customers,ou=Headquarter,dc=example,dc=com The BaseDN you used to be using is: ou=Headquarter,dc=example,dc=com
Now, use this for the BaseDN when it comes to Customers: ou=Customers,ou=Headquarter,dc=example,dc=com And this one, when it comes to Agent AUTH: ou=People,ou=Headquarter,dc=example,dc=com
If you have both your Agents and your Customers cluttered in: ou=People,ou=Headquarter,dc=example,dc=com Then it's time for a cleanup, I presume.
I believe there must be another way to logically distinguish your Customers from your Agents in your AD, but I know too little of it, sorry. If the above is no option at all, we'll dig further.
hth,
Robert Kehl
-- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support oder Consulting für Ihr OTRS System? => http://www.otrs.de/
DISCLAIMER: This message contains information that may be privileged or confidential and is the property of the Roxar Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorised to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

On Friday, March 26, 2004 8:54 AM
Thomas Nilsen
If I could only find the code which allows this agent registration, I could comment it out and the problem would be solved...
SyncLDAP2Database{} is from Kernel/System/User.pm, but you needn't change s.th. there. The sub takes $Self->{UserSyncLDAPMap} from Config.pm and synchs the user from LDAP to DB if the user isn't found in the latter, but LDAP AUTH is activated. For sure the user must exist in the LDAP database. In fact, LDAP AUTH is nothing more than Synching an LDAP entry to the DB and authenticating against this entry. So, to conclude - switching of the Sync will take away the ability to log on as a new user, yes. But every user that you want to log on has to exist in the DB prior to switching of the capability. The trigger can be found in index.pl, line 197 (v 1.66): if ($CommonObject{UserObject}->SyncLDAP2Database(User => $User)) { You may easily switch off Synching by setting $Self->{UserSyncLDAPMap} = {}; Now only the LDAP users already existing in the DB _and_ LDAP can log in, no new entries will be created. This is not the recommended approach, though! There must be a way that you distinguish the administrator of your groups by a common property. Aren't their account types different? Isn't it even possible to create a new posix-conform group in AD? hth, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
participants (2)
-
Robert Kehl
-
Thomas Nilsen