Hallo zusammen,
ist es prinzipiell möglich, OTRS so für LDAP zu konfigurieren, dass sich alle User, die im Active Directory verwaltet werden, am OTRS anmelden können ohne Ihnen dort vorher explizit einen Zugang einzurichten? Unsere Mitarbeiter sind ohnehin schon im ADS und könnten sich dann automatisch auch bei OTRS anmelden. Ich habe gelesen, dass Accounts für OTRS im OTRS für jeden Benutzer (in unserem Intranet) einzeln angelegt werden müssten. Führt daran wirklich kein Weg vorbei, bzw. kann das dann wenigstens halbautomatische geschehen, ich meine indem mehrere Accounts auf einmal angelegt werden?
Meine Wunschvorstellung wäre ein Mapping zwischen Gruppen im Active Directory und Gruppen im OTRS, sodass wir unsere Mitarbeiter nur verschiedenen Gruppen im ADS zuordnen müssen, um auch der entsprechenden OTRS-Gruppen anzugehören. Für unsere Kunden möchte ich dann extra Benutzer in geeigneten Gruppen im ADS anlegen, die dann automatisch der passenden OTRS-Gruppe angehören. Von einem solchen Mapping habe ich aber nur für die User gelesen. Kann mir jemand bei diesem Problem helfen?
Grüsse, Thomas
ADS: Auth & Mapping auf OTRS-Gruppen
ADS: Auth & Mapping auf OTRS-Gruppen
Hallo,
für die Agenten ist das ohne Probleme möglich.
Bei den Kunden würde ich generell von Gruppen absehen.
Grüße
für die Agenten ist das ohne Probleme möglich.
Bei den Kunden würde ich generell von Gruppen absehen.
Grüße
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master
Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
"Testing": ((OTRS Community Edition)) and git Master
Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
ADS: Auth & Mapping auf OTRS-Gruppen
Hallo zusammen,
vielen Dank für die Informationen des ganzen Forums. Nach vielen Fehlversuchen klappt es jetzt bei uns tadellos, dass nur User sich als Agenten anmelden können, die der Active Directory-Gruppe OTRS_Agents angehören. Verbliebene Fragen:
1) Die Anmeldung der User in OTRS_Agents ist nur möglich, wenn sie zuvor im OTRS ohne PW als Agenten angelegt worden sind. Lässt sich dieser Aufwand umgehen? Sprich, kann man nicht mit einem geplanten Task regelmäßig alle User im ADS in der OTRS-DB als Agenten eintragen?
Über die Gruppe OTRS_Agents kann ich ja dann immer noch steuern, wer bei uns tatsächlich Agentenrechte hat.
2) Ferner möchte ich, dass unser OTRS für jede Queue eine Email-Adresse hat, an die Supportbedürftige Anfragen schicken können. OTRS soll dann automatisch ein Ticket erzeugen und eine Antwort mit der Ticketnummer verschicken. Zu diesem Thema habe ich leider noch keine passende Quelle gefunden.
Wer kann mir helfen?
Vielen Dank im Voraus,
Thomas
vielen Dank für die Informationen des ganzen Forums. Nach vielen Fehlversuchen klappt es jetzt bei uns tadellos, dass nur User sich als Agenten anmelden können, die der Active Directory-Gruppe OTRS_Agents angehören. Verbliebene Fragen:
1) Die Anmeldung der User in OTRS_Agents ist nur möglich, wenn sie zuvor im OTRS ohne PW als Agenten angelegt worden sind. Lässt sich dieser Aufwand umgehen? Sprich, kann man nicht mit einem geplanten Task regelmäßig alle User im ADS in der OTRS-DB als Agenten eintragen?
Über die Gruppe OTRS_Agents kann ich ja dann immer noch steuern, wer bei uns tatsächlich Agentenrechte hat.
2) Ferner möchte ich, dass unser OTRS für jede Queue eine Email-Adresse hat, an die Supportbedürftige Anfragen schicken können. OTRS soll dann automatisch ein Ticket erzeugen und eine Antwort mit der Ticketnummer verschicken. Zu diesem Thema habe ich leider noch keine passende Quelle gefunden.
Wer kann mir helfen?
Vielen Dank im Voraus,
Thomas
ADS: Auth & Mapping auf OTRS-Gruppen
1) ja, such mal nach Sync in der Defaults.pm
2) ja, Autoantworten helfen...
2) ja, Autoantworten helfen...
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master
Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
"Testing": ((OTRS Community Edition)) and git Master
Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
ADS: Auth & Mapping auf OTRS-Gruppen
Hallo zusammen,
vielen Dank für die Hinweise. Ich habe das Gefühl, gut voranzukommen und immer mehr zu verstehen, aber leider klappts doch nicht so richtig.
Das mit dem Sync hat mir sofort eingeleuchtet; ich fand UserSyncLDAPMap, UserSyncLDAPGroups und UserSyncLDAPGroupsDefination müssten relevant sein.
... hatte ich in meiner Config.pm schon drin und vermutlich hatte die Agentenanmeldung bei Benutzern, die nicht im OTRS explizit ohne PW angelegt worden waren, auf Grund von UserSyncLDAPGroups doch schon geklappt, macht das Sinn?
2. Woran ich dann aber arbeitete, war mapping von ADS-Gruppen auf OTRS-Gruppen. In OTRS habe ich also erstmal die Gruppen GruppeA und GruppeB angelegt. Im ADS habe ich dann in der für OTRS angelegten OU die Gruppen GruppeA, GruppeB und Administrators definiert, um unseren Mitarbeitern entsprechend auf den OTRS-Gruppen GruppeA und GruppeB zu berechtigen bzw. ihnen im OTRS Admin-Rechte zu geben. Mit dem unten angegebenen Code in der Config.pm wollte ich die Zuordnung realisieren, habe damit aber stattdessen erreicht, dass ich mich mit meinem eigenen Benutzernamen und regulärem (Wondows-)-Passwort zwar noch anmelden kann, aber jetzt keinen Admin-Bereich mehr zur Verfügung habe. Also UserSyncLDAPGroupsDefination schnell wieder auskommentiert, aber den Admin-Bereich habe ich immer noch nicht. Wie kann ich das reparieren?
3. Es war für mich leider auch nicht klar, ob man etwa grundsätzlich nur einen der Parameter UserSyncLDAPGroups und 'UserSyncLDAPGroupsDefination' benötigt, ersteren etwa wenn man gar keine unterschiedlichen Gruppen will, sondern nur allgemein 'users' kennt und letzteren wenn differenziertere Berechtigungen benötigt werden. Gibt es eine Quelle, in der die Wirkungen der verschiedenen Syncs beschrieben sind?
Vielen Dank im Voraus,
Thomas
Der Vollständigkeit halber noch die heutigen Einträge im Log:
vielen Dank für die Hinweise. Ich habe das Gefühl, gut voranzukommen und immer mehr zu verstehen, aber leider klappts doch nicht so richtig.
Das mit dem Sync hat mir sofort eingeleuchtet; ich fand UserSyncLDAPMap, UserSyncLDAPGroups und UserSyncLDAPGroupsDefination müssten relevant sein.
Code: Select all
$Self->{UserSyncLDAPMap} = {
# DB -> LDAP
UserFirstname => 'givenName',
UserLastname => 'sn',
UserEmail => 'mail',
};
$Self->{UserSyncLDAPGroups} = [
'users',
];
2. Woran ich dann aber arbeitete, war mapping von ADS-Gruppen auf OTRS-Gruppen. In OTRS habe ich also erstmal die Gruppen GruppeA und GruppeB angelegt. Im ADS habe ich dann in der für OTRS angelegten OU die Gruppen GruppeA, GruppeB und Administrators definiert, um unseren Mitarbeitern entsprechend auf den OTRS-Gruppen GruppeA und GruppeB zu berechtigen bzw. ihnen im OTRS Admin-Rechte zu geben. Mit dem unten angegebenen Code in der Config.pm wollte ich die Zuordnung realisieren, habe damit aber stattdessen erreicht, dass ich mich mit meinem eigenen Benutzernamen und regulärem (Wondows-)-Passwort zwar noch anmelden kann, aber jetzt keinen Admin-Bereich mehr zur Verfügung habe. Also UserSyncLDAPGroupsDefination schnell wieder auskommentiert, aber den Admin-Bereich habe ich immer noch nicht. Wie kann ich das reparieren?
3. Es war für mich leider auch nicht klar, ob man etwa grundsätzlich nur einen der Parameter UserSyncLDAPGroups und 'UserSyncLDAPGroupsDefination' benötigt, ersteren etwa wenn man gar keine unterschiedlichen Gruppen will, sondern nur allgemein 'users' kennt und letzteren wenn differenziertere Berechtigungen benötigt werden. Gibt es eine Quelle, in der die Wirkungen der verschiedenen Syncs beschrieben sind?
Vielen Dank im Voraus,
Thomas
Code: Select all
$Self->{'UserSyncLDAPGroupsDefination'} = {
# ldap group
'CN=Administrators,OU=OTRS,OU=Kopf,DC=intranet,DC=domain,DC=com' => {
# otrs group
'admin' => { rw => 1, ro => 1, },
'GruppeA' => { rw => 1, ro => 1, },
'GruppeB' => { rw => 1, ro => 1, }
},
'CN=GruppeA,OU=OTRS,OU=Kopf,DC=intranet,DC=domain,DC=com' => {
# otrs group
'GruppeA' => { rw => 1, ro => 1, }
},
'CN=GruppeB,OU=OTRS,OU=Kopf,DC=intranet,DC=domain,DC=com' => {
# otrs group
'GruppeB' => { rw => 1, ro => 1, }
}
};
Code: Select all
[Thu Mar 20 09:00:02 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 09:20:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 09:40:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 10:00:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 10:20:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 10:40:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 11:00:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 11:14:42 2008][Notice][Kernel::System::Auth::LDAP::Auth] User: Login (CN=Nachname\, Vorname,OU=OfficeWS,OU=Mitarbeiter,OU=Benutzer,OU=Kopf,DC=intranet,DC=domain,DC=com) authentication ok (REMOTE_ADDR: 192.168.10.12).
[Thu Mar 20 11:14:43 2008][Notice][Kernel::System::User::UserUpdate] User: 'Login' updated successfully (1)!
[Thu Mar 20 11:14:43 2008][Notice][Kernel::System::User::SetPassword] User: 'Login' changed password successfully!
[Thu Mar 20 11:14:59 2008][Notice][Kernel::System::AuthSession::DB::RemoveSessionID] Removed SessionID 10321401718172fb58798045bda0d9895c.
[Thu Mar 20 11:20:02 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 11:40:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 12:00:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 12:20:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 12:40:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 13:00:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 13:20:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 13:40:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 14:00:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 14:20:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 14:40:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 14:42:03 2008][Notice][Kernel::System::Auth::LDAP::Auth] User: Login (CN=Nachname\, Vorname,OU=OfficeWS,OU=Mitarbeiter,OU=Benutzer,OU=Kopf,DC=intranet,DC=domain,DC=com) authentication ok (REMOTE_ADDR: 192.168.10.12).
[Thu Mar 20 14:42:03 2008][Notice][Kernel::System::User::UserUpdate] User: 'Login' updated successfully (1)!
[Thu Mar 20 14:42:03 2008][Notice][Kernel::System::User::SetPassword] User: 'Login' changed password successfully!
[Thu Mar 20 14:42:21 2008][Notice][Kernel::System::AuthSession::DB::RemoveSessionID] Removed SessionID 10f8370a35ebfef6cf098d57e9a0899431.
[Thu Mar 20 14:49:30 2008][Error][Kernel::System::AuthSession::DB::GetSessionIDData][130] Got no SessionID!!
[Thu Mar 20 14:49:30 2008][Notice][Kernel::System::AuthSession::DB::CheckSessionID] SessionID: '' is invalid!!!
[Thu Mar 20 14:49:39 2008][Notice][Kernel::System::Auth::LDAP::Auth] User: Login (CN=Nachname\, Vorname,OU=OfficeWS,OU=Mitarbeiter,OU=Benutzer,OU=Kopf,DC=intranet,DC=domain,DC=com) authentication ok (REMOTE_ADDR: 192.168.10.12).
[Thu Mar 20 14:49:39 2008][Notice][Kernel::System::User::UserUpdate] User: 'Login' updated successfully (1)!
[Thu Mar 20 14:49:39 2008][Notice][Kernel::System::User::SetPassword] User: 'Login' changed password successfully!
[Thu Mar 20 14:49:46 2008][Notice][Kernel::System::AuthSession::DB::RemoveSessionID] Removed SessionID 1043d865545d03b84797776a639fdbff0e.
[Thu Mar 20 15:00:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
[Thu Mar 20 15:20:01 2008][Error][C:/OTRS/otrs/bin/GenericAgent.pl][100] Module 'Kernel::Config::GenericAgent' not found!
ADS: Auth & Mapping auf OTRS-Gruppen
Hallo zusammen,
da diese Ecke auch gerade meine Baustelle ist, hier ein paar Erfahrungen meinerseits:
1. UserSyncLDAPGroups legt statisch die Gruppen der Aufzählung an und gibt den Benutzern rw Rechte -- habe ich wieder aus der Konfiguraion eliminiert.
2. Interessanter ist UserSyncLDAPGroupsDefination das ein Mapping macht von LDAP auf OTRS Gruppen. Ein Blick in den Code (OTRS 2.2.5) zeigt, dass die Funktion erst alle Rechte des Users in OTRS löscht um dann gemäß des Gruppenmappings diese neu zu vergeben. Dies funktioniert alles sehr schön, solange der User (agent) nur in einer der LDAP Gruppen ist, da die Funktion die Rechte für die Gruppe komplett neu schreibt. Dies heißt es wird jeweils für die OTRS Gruppe die Maske mit den Flags ro, create, move_into, priority, owner, rw als invalid gesetzt und dann die Rechte aus der Konfig addiert. Wenn der User zu mehreren gemappten LDAP Gruppen gehört gilt daher, das Mapping das zum Schluss geschrieben wird gewinnt. Mit der Reihenfolge in der Konfig-Datei hat dies nicht zu tuen.
Es können alle Flags (ro, create, move_into, priority, owner, rw) mit UserSyncLDAPGroupsDefination gesetzt werden.
Will man dies ändern muß die /otrs/Kernel/System/Auth/LDAP.pm ändern. Am Ende der Funktion UserSyncLDAPGroupsDefination findert sich:
$Self->{GroupObject}->GroupMemberAdd(
GID => $GroupID,
UID => $UserData{UserID},
Permissions => {
# %PermissionsEmpty, ##DIESE ZEILE auskommentieren
%Permissions,
}
UserID => 1,
);
Wenn dann in der Konfig nur zu setzende Rechte stehen, addieren sich die Rechte über die Gruppen denen der User angehört !
3. Wenn man kein Admin Icon/Link mehr im Menü hat, ist wegen dem Löschen der OTRS-Rechte die Gruppenzugehörigkeit gelöscht. Also mal in der Datenbank in die Tabelle group_user schauen und für den User permission_value von 0 auf 1 setzen.
Cheers!
da diese Ecke auch gerade meine Baustelle ist, hier ein paar Erfahrungen meinerseits:
1. UserSyncLDAPGroups legt statisch die Gruppen der Aufzählung an und gibt den Benutzern rw Rechte -- habe ich wieder aus der Konfiguraion eliminiert.
2. Interessanter ist UserSyncLDAPGroupsDefination das ein Mapping macht von LDAP auf OTRS Gruppen. Ein Blick in den Code (OTRS 2.2.5) zeigt, dass die Funktion erst alle Rechte des Users in OTRS löscht um dann gemäß des Gruppenmappings diese neu zu vergeben. Dies funktioniert alles sehr schön, solange der User (agent) nur in einer der LDAP Gruppen ist, da die Funktion die Rechte für die Gruppe komplett neu schreibt. Dies heißt es wird jeweils für die OTRS Gruppe die Maske mit den Flags ro, create, move_into, priority, owner, rw als invalid gesetzt und dann die Rechte aus der Konfig addiert. Wenn der User zu mehreren gemappten LDAP Gruppen gehört gilt daher, das Mapping das zum Schluss geschrieben wird gewinnt. Mit der Reihenfolge in der Konfig-Datei hat dies nicht zu tuen.
Es können alle Flags (ro, create, move_into, priority, owner, rw) mit UserSyncLDAPGroupsDefination gesetzt werden.
Will man dies ändern muß die /otrs/Kernel/System/Auth/LDAP.pm ändern. Am Ende der Funktion UserSyncLDAPGroupsDefination findert sich:
$Self->{GroupObject}->GroupMemberAdd(
GID => $GroupID,
UID => $UserData{UserID},
Permissions => {
# %PermissionsEmpty, ##DIESE ZEILE auskommentieren
%Permissions,
}
UserID => 1,
);
Wenn dann in der Konfig nur zu setzende Rechte stehen, addieren sich die Rechte über die Gruppen denen der User angehört !
3. Wenn man kein Admin Icon/Link mehr im Menü hat, ist wegen dem Löschen der OTRS-Rechte die Gruppenzugehörigkeit gelöscht. Also mal in der Datenbank in die Tabelle group_user schauen und für den User permission_value von 0 auf 1 setzen.
Cheers!
ADS: Auth & Mapping auf OTRS-Gruppen
Super, der Admin-Bereich ist wieder da!
Hinreichend waran der Config.pm hat sich nichts geändert, ich will klein anfangen und die Funktion erst für die 2 Testgruppen GruppeA und GruppeB sicherstellen.
Leider scheint mir der Prozess, eine neue Queue mit Emailadresse einzurichten, etwas aufwändig zu sein, sofern ich ihn richtig verstanden habe.
Ich vermute, um eine neue Queue yyyQ einzurichten, müssen wir:
Hinreichend war
Code: Select all
update group_user set permission_value=1 where user_id=2 and group_id=2;Leider scheint mir der Prozess, eine neue Queue mit Emailadresse einzurichten, etwas aufwändig zu sein, sofern ich ihn richtig verstanden habe.
Ich vermute, um eine neue Queue yyyQ einzurichten, müssen wir:
- 1. diese im OTRS-Adminbereich zusammen mit einer auf ihr berechtigten OTRS-Gruppe yyyG anlegen,
2. den Benutzeraccount yyyM mit Postfach auf dem Mailserver einrichten,
3.in der POP3-Kontenverwaltung yyyM mit PW, Mailserver und zugeordneter Queue yyyQ hinzufügen,
4. eine ADS-Gruppe yyyA mit allen Benutzern anlegen, die berechtigt sein sollen, mit yyyQ zu arbeiten und
5. die Gruppe yyyA in der Config.pm mittels 'UserSyncLDAPGroupsDefination' mit yyyG verknüpfen.
- Es stellt sich für mich die Frage, ob dieses Ziel auch einfacher erreicht werden kann (vielleicht mit Rollen?) und ob sich der beschriebene Prozess überhaupt mit Euren Erfahrungen deckt?
- Ist es richtig, dass Autoantworten gar nicht benötigt werden, wenn wir den Kundenbereich nicht nutzen wollen, sondern lediglich Tickets bequem per Email erstellen und als Agents bearbeiten wollen und somit keine Ticketnummer eingeben müssen?
ADS: Auth & Mapping auf OTRS-Gruppen
Hallo zusammen,
bin kürzlich wieder dazu gekommen, mich mit unserem Testsystem zu beschäftigen und habe die einzelnen Schritte 1.-5. manuell durchgeführt. Ich befürchte, dass es tatsächlich nicht einfacher geht, weil schliesslich alle Schritte von der Problemstellung her motiviert sind.
Mein Ergebnis:
Einfacher kann die Bereitstelung einer neuen Queue nur werden, wenn man Skripte schreibt, die die Ergänzungen im ADS vornehmen und im nächsten Schritt auch noch durch den Start geeigneter OTRS-Admin-Skripts in der OTRS-DB die neue Queue, eine entsprechende Gruppe und die Verknüpfung mit einem POP3-Mailaccount eintragen. Gibt es solche Skripte vielleicht schon?
Ich denke dabei an etwas wie z.B. \OTRS\otrs\scripts\tools\sync-ldap2db.pl, das ja auch auf Grund einer Abfrage des ADS Benutzerdaten in die lokale DB einträgt. Weiss jemand, ob es genügen würde, dieses Skript für meinen Zweck anzupassen oder ob dafür ein ganz neues Skript entwickelt werden müsste?
Meine weiteren Überlegungen gehen dahin statt UserSyncLDAPGroupsDefination vielleicht besser UserSyncLDAPRolesDefination zu verwenden. Dann könnte ich beispielsweise die ADS-Gruppe "OTRS\groups\Administrators" in eine OTRS-Rolle admins synchronisieren, die die Rechte aller Gruppen vereint, sofern das gewünscht ist. Das hätte allerdings den Nachteil, dass für jede Queue nicht nur eine Gruppe sondern zusätzlich auch noch eine Rolle benötigt wird, weil doch die ADS-Benutzergruppen jetzt Rollen zugenordnet werden, die für sich auf Queues nur via Gruppen berechtigt sind.
Grüsse, Thomas
bin kürzlich wieder dazu gekommen, mich mit unserem Testsystem zu beschäftigen und habe die einzelnen Schritte 1.-5. manuell durchgeführt. Ich befürchte, dass es tatsächlich nicht einfacher geht, weil schliesslich alle Schritte von der Problemstellung her motiviert sind.
Mein Ergebnis:
- Als Admin-Benutzer sehe ich, dass alle Benutzer, die bereits in die OTRS-DB synchronisiert worden sind, auf genau den Gruppen berechtigt sind, die ich mit UserSyncLDAPGroupsDefination den entsprechenden ADS-Gruppen zugeordnet hatte.
- Ein Eingang in den für diese Gruppen bzw. Queues vorgesehenen Postfächern hat leider noch keine Ticketerzeugung zu Folge. Nach dem, was ich in OTRS bereits gesehen habe, muss sich dieses Poblem mit der POP3-Kontenverwaltung lösen lassen.
Einfacher kann die Bereitstelung einer neuen Queue nur werden, wenn man Skripte schreibt, die die Ergänzungen im ADS vornehmen und im nächsten Schritt auch noch durch den Start geeigneter OTRS-Admin-Skripts in der OTRS-DB die neue Queue, eine entsprechende Gruppe und die Verknüpfung mit einem POP3-Mailaccount eintragen. Gibt es solche Skripte vielleicht schon?
Ich denke dabei an etwas wie z.B. \OTRS\otrs\scripts\tools\sync-ldap2db.pl, das ja auch auf Grund einer Abfrage des ADS Benutzerdaten in die lokale DB einträgt. Weiss jemand, ob es genügen würde, dieses Skript für meinen Zweck anzupassen oder ob dafür ein ganz neues Skript entwickelt werden müsste?
Meine weiteren Überlegungen gehen dahin statt UserSyncLDAPGroupsDefination vielleicht besser UserSyncLDAPRolesDefination zu verwenden. Dann könnte ich beispielsweise die ADS-Gruppe "OTRS\groups\Administrators" in eine OTRS-Rolle admins synchronisieren, die die Rechte aller Gruppen vereint, sofern das gewünscht ist. Das hätte allerdings den Nachteil, dass für jede Queue nicht nur eine Gruppe sondern zusätzlich auch noch eine Rolle benötigt wird, weil doch die ADS-Benutzergruppen jetzt Rollen zugenordnet werden, die für sich auf Queues nur via Gruppen berechtigt sind.
- 1. Oder kann man UserSyncLDAPGroupsDefination und UserSyncLDAPRolesDefination auch gemeinsam verwenden?
2. Und ist es möglich, in der Config.pm eine ganze OU zu traversieren, um jede ADS-Gruppe in ihr in entsprechende OTRS-Gruppen oder -Rollen zu synchronisieren?
Das hätte den entscheidenden Vorteil, dass nicht mit jeder neuen Queue die Einstellungen für UserSyncLDAPGroupsDefination oder UserSyncLDAPRolesDefination in der Conifg.pm ergänzt werden müssten, was sich allerdings auch mit einem Perl-Skript erledigen liesse.
Grüsse, Thomas