We could disable the UserSyncLDAPMap, but that would also prevent new customer users from logging on to the customer part of Otrs, or would it not?
We are happy managing the admin users directly in the SQL table, but customer users would be too many to do manually... Active Directory seems to use the users SID id for group memberships. If Otrs checked the "memberOf" attribute on the user we would be ok, but it is not possible to check the group directly to see if username xxx belongs to it - without using the accounts SID. I'll do some more digging on AD and LDAP and see what the group system is all about. It's not a major issue anyway, but it would be nice to have a clean admin user list.. Thanks, Thomas >-----Original Message----- >From: Robert Kehl [mailto:[EMAIL PROTECTED] >Sent: Friday, March 26, 2004 12:00 PM >To: User questions and discussions about OTRS. >Subject: Re: [otrs] Limit Agent user registration > > >On Friday, March 26, 2004 8:54 AM >Thomas Nilsen <[EMAIL PROTECTED]> wrote: >> 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 > >_______________________________________________ >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. _______________________________________________ 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/
