LDAP Kunden ohne Zugang / Kunden fehlen ganz

[Ronnenberg]

Hallo Community und frohes neues Jahr!

Habe schon an die Mailing-Liste geschrieben, aber noch keine Antwort erhalten. Daher versuche ich es hier nochmal:

In meinem OTRS-System scheine ich gleich 2 Probleme mit meinen Kunden zu
haben. Ich weiß nicht, ob die Ursache beider Probleme die selbe ist. Ich
versuche es mal darzulegen.

1. Unter Admin --> Kunden bekomme ich bereits sehr viele Kundenbenutzer
angezeigt, die sich OTRS offensichtlich aus dem LDAP Verzeichnisdienst
holt. ABER, merkwürdigerweise fehlen hier mehrere. Diejenigen die fehlen
folgen allerdings auch keinem System. Wenn ich jedoch ein neues
Telefonticket aufnehme, werden mir tatsächlich alle Kunden angezeigt,
die im Verzeichnisdienst sind (auch die, die unter Admin --> Kunden
fehlen).
Wie kann das kommen?

2. Wenn ich mich als Kunde im Kundenfrontend anmelden will - es spielt
keine Rolle ob als einer der vorhandenen oder einer der fehlenden -
erhalte ich die Fehlermeldung
"Authentication succeeded, but no customer record is found in the
customer backend. Please contact your administrator."
Was habe ich hier vergessen?

Viele Grüße und Danke im Voraus für eure Hilfe!

[thomas91]

Hi Ronnenberg,

bitte schrebe doch in deiner Signatur was für eine Version OTRS auf welchem OS du nutzt...
So kann dir niemand weiter helfen, da man nicht weis welche OTRS Version du verwendest!

[Wolfgangf]

1) da ist ein Limit eingebaut, deshalb siehst Du nicht alle; soweit ich mich erinnern kann nur die ersten 300 oder so
eine weitere quelle könnte eine Filterbedingung in der LDAP config sein; etwas wie

Code: Select all

$Self->{'AuthModule::LDAP::AlwaysFilter'} =  '(&(objectclass=user)(mail=*))';

das schränkt natürlich das Suchergebnis

2) hier würde Deine Config helfen - allerdings wurde die gleiche Frage schon x mal hier gestellt; hast Du schon gesucht im Forum?

[Ronnenberg]

bitte schrebe doch in deiner Signatur was für eine Version OTRS auf welchem OS du nutzt...
So kann dir niemand weiter helfen, da man nicht weis welche OTRS Version du verwendest!

Gute Einwand, ist erledigt!

1) da ist ein Limit eingebaut, deshalb siehst Du nicht alle; soweit ich mich erinnern kann nur die ersten 300 oder so
eine weitere quelle könnte eine Filterbedingung in der LDAP config sein; etwas wie

Code: Select all

$Self->{'AuthModule::LDAP::AlwaysFilter'} =  '(&(objectclass=user)(mail=*))';

das schränkt natürlich das Suchergebnis

2) hier würde Deine Config helfen - allerdings wurde die gleiche Frage schon x mal hier gestellt; hast Du schon gesucht im Forum?

Nummer 1 hab ich entdeckt, das war offensichtlich

Code: Select all

CustomerUserSearchListLimit => 250

Hab´s geändert auf 500 und jetzt stehen alle dort.

Zu 2: Ja, ich hab gesucht, allerdings kann ich mit den Ergebnissen leider nichts anfangen, da ich aus den Config-Beispielen in diesen Threads nicht den Eintrag rausfiltern kann, der für mich funktioniert. Ich hab leider auch nicht allzuviel Ahnung von LDAP, bzw. fuchse mich gerade erst in die gesamte Thematik ein.
Vielleicht kannst Du ja etwas entdecken, dass direkt völlig falsch ist. Hier die relevanten Parts meiner Kernel/Config.pm:

Code: Select all

      # This is an example configuration for an LDAP auth. backend.
      # (take care that Net::LDAP is installed!)
      $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
      $Self->{'Customer::AuthModule::LDAP::Host'} = 'ldaps://10.13.10.23';
      $Self->{'Customer::AuthModule::LDAP::BaseDN'} = '';
      $Self->{'Customer::AuthModule::LDAP::UID'} = 'cn';


        # CustomerUser
        # (customer user ldap backend and settings)
        $Self->{CustomerUser} = {
            Name => 'LDAP Datenquelle',
            Module => 'Kernel::System::CustomerUser::LDAP',
            Params => {
                # ldap host
                Host => 'ldaps://10.13.10.23',
                # ldap base dn
                BaseDN => '',
                # search scope (one|sub)
                SSCOPE => 'sub',
    #            # The following is valid but would only be necessary if the
    #            # anonymous user does NOT have permission to read from the LDAP tree
                UserDN => 'CN=LDAP_Proxy,o=rathaus',
                UserPw => '',
                # in case you want to add always one filter to each ldap query, use
                # this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)'
                AlwaysFilter => '(objectclass=user)',
                # if your frontend is e. g. iso-8859-1 and the charset of your
                # ldap server is utf-8, use this options (if not, ignore it)
    #            SourceCharset => 'utf-8',
    #            DestCharset => 'iso-8859-1',
                # Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
                Params => {
                    port => 636,
                    timeout => 120,
                    async => 0,
                    version => 2,
		    cafile => '/etc/ssl/certs/test.der'
                },
            },
            # customer uniq id
            CustomerKey => 'mail',
            # customer #
            CustomerID => 'mail',
            CustomerUserListFields => ['mail'],
            CustomerUserSearchFields => ['mail'],
            CustomerUserSearchPrefix => '*',
            CustomerUserSearchSuffix => '*',
            CustomerUserSearchListLimit => 500,
            CustomerUserPostMasterSearchFields => ['mail'],
            CustomerUserNameFields => ['givenname', 'sn'],
            # show not own tickets in customer panel, CompanyTickets
            CustomerUserExcludePrimaryCustomerID => 0,
            # add a ldap filter for valid users (expert setting)
    #       CustomerUserValidFilter => '(!(description=gesperrt))',
            # admin can't change customer preferences
            AdminSetPreferences => 0,
    #        # cache time to life in sec. - cache any database queris
    #        CacheTTL => 0,
            Map => [
                # note: Login, Email and CustomerID needed!
                # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly
    #            [ 'UserSalutation', 'Title',      'title',           1, 0, 'var', '', 0 ],
                [ 'UserFirstname',  'Firstname',  'givenname',       1, 1, 'var', '', 0 ],
                [ 'UserLastname',   'Lastname',   'sn',              1, 1, 'var', '', 0 ],
                [ 'UserLogin',      'Username',   'cn',             1, 1, 'var', '', 0 ],
                [ 'UserEmail',      'Email',      'mail',            1, 1, 'var', '', 0 ],
                [ 'UserCustomerID', 'CustomerID', 'mail',            0, 1, 'var', '', 0 ],
    #            [ 'UserCustomerIDs', 'CustomerIDs', 'second_customer_ids', 1, 0, 'var', '', 0 ],
    #            [ 'UserPhone',      'Phone',      'telephonenumber', 1, 0, 'var', '', 0 ],
    #            [ 'UserAddress',    'Address',    'postaladdress',   1, 0, 'var', '', 0 ],
    #            [ 'UserComment',    'Comment',    'description',     1, 0, 'var', '', 0 ],
            ],
        };

Das Passwort hab ich selbstverständlich rausgenommen und die Base DN ist leer, da er direkt im Root anfangen soll zu suchen, denn wir haben mehrere "Organizations" (LDAP: O=) in denen sich Nutzer finden, die alle das selbe OTRS nutzen sollen.

Grüße
Leo

[Wolfgangf]

Hi!

Ich denke, dass es an den "CustomerKey" settings liegt; verwende hier mal "samaccountname" statt der EMailadresse

Ich habe bei

Code: Select all

$Self->{'Customer::AuthModule::LDAP::UID'} nicht 'cn' sondern 'sAMAccountName'

beim AlwaysFilter verwende ich

Code: Select all

AlwaysFilter =>  '(&(objectclass=user)(mail=*))',

weil ja jeder Kunde eine gültige EMail Adresse haben muss
und hier noch meine Settings zu Customerkey ...

Code: Select all

$Self->{CustomerUser1} = {
	CustomerKey => 'sAMAccountName',
	CustomerID => 'mail',
	CustomerUserListFields => ['cn', 'mail'],
	CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],
	CustomerUserSearchListLimit => 1000,
	CustomerUserPostMasterSearchFields => ['mail'],
	CustomerUserNameFields => ['givenname', 'sn'],
	CustomerUserExcludePrimaryCustomerID => 0,
	AdminSetPreferences => 0,

[Ronnenberg]

Hi Wolfgang,

danke für den Tipp!
samaccountname war´s nicht. Wir haben kein Active Directory (hätte ich vielleicht von vorn herein erwähnen sollen), sondern Novell eDirectory. Da ist der Benutzername cn, wobei der nicht eindeutig ist, was das System ja verlangt. Wenn ich
$Self->{'Customer::AuthModule::LDAP::UID'} = 'mail';
einstelle, dann kann ich mich als Kunde mit meiner E-Mail Adresse als Benutzernamen anmelden.
Damit bin ich schonmal einen großen Schritt weiter.

Aber da kommt gleich das nächste Problem:
Ich kann mich zwar nun als Kunde einloggen und sehe meine Tickets, aber ich komm in kein einziges rein.
Ich halte jedesmal beim Klick auf ein Ticket

Code: Select all

Nicht ausreichende Rechte
Nachricht: No Permission! 

Im Systemprotokoll ist dann

Code: Select all

Permission denied (UserID: edv 'ro' on TicketID: 336)!

zu finden.

Wenn ich im Admin-Bereich in die Kunden-Gruppen-Zuorndung schaue, ist bei den Benutzern nirgends etwas angehakt.
Wenn ich ein Häkchen für eine Gruppe (EDV) setze, speichert er dies allerdings nicht. Was habe ich hier nu wieder vergessen?

Grüße

[Ronnenberg]

Hat denn keiner eine Idee?

Grüße

[boris]

ich hatte auch mal probleme Rechte zu speichern,
ich hatte die customer nicht ordentlich gefiltert.
und es wurden nicht genug angezeigt.

Steht hier:
http://forums.otrs.org/viewtopic.php?f=17&t=7516

[Ronnenberg]

Hi!

Danke für Deinen Tipp! Aber was meinst Du mit customer filtern?
Was muss ich da wie machen? In Deinem thread ging´s wohl nur um´s SearchLimit.

Grüße

[boris]

oh jetzt bin ich mit den Threads durcheinander gekommen
Sowas mein ich:

Code: Select all

AlwaysFilter =>  '(&(objectclass=user)(mail=*.*@Firma.de))',

Das hatte ich bei mir Angangs nicht drin. Da würden dann auch Serviceaccounts usw gemappt.
Bei der Kunden-Gruppenzuordung hats dann Fehler geschmissen.

Was steht denn bei dir im log?

[Ronnenberg]

Das Einloggen als Kunde klappt wunderbar und ich sehe die Tickets.
Aber sobald ich als Kunde ein Ticket öffnen will, erhalte ich nur "Permission denied".

Im Log steht dann
Permission denied (UserID: edv 'ro' on TicketID: 414)!

[jojo]

Hast Du CustomerGroup Support eingeschaltet? Wenn ja warum?

[boris]

und die customer<->Groups Zuweisung klappt immer noch nicht?

[Ronnenberg]

Hast Du CustomerGroup Support eingeschaltet? Wenn ja warum?

Habs beides probiert. Spielt keine Rolle ob ich CustomerGroup Support aktiviere oder nicht. Kommt beides mal der selbe Fehler.
Ich war ja ganz happy als ich es aktiviert hatte und dort mittels Rechtevergabe steuern konnte, wer wo drauf Zugriff hat und dort hab ich auch des Rätsels Lösung vermutet.
Allerdings - als ich die Rechte angeklickt hatte unter Customer <-> Groups - speichert er die Einstellungen nicht. Wenn man die Seite neu aufruft sind keine Haken mehr gesetzt...

[boris]

dann muss ich passen.
bei mir hat es nicht alle haken gesetzt, daß hat sich aber dann dank dem Filter erledigt.

[Ronnenberg]

So, ich habe eine Lösung gefunden, es funktioniert nun.
Ich sehe nun noch 1 Problemchen das eher persönlicher Natur ist: Ich weiß zwar, was ich geändert habe, aber ich weiß nicht genau, was ich gemacht habe Ich hoffe ihr versteht mich . Also, folgendes habe ich geändert:
In Kernel\Config.pm habe ich die Einträge

Code: Select all

$Self->{'Customer::AuthModule::LDAP::UID'} = 'cn';
CustomerKey => 'cn',
CustomerID => 'cn',

geändert. Sie hatten den Wert 'mail', jetzt habe ich alle auf 'cn' gesetzt. CN ist in unserem LDAP-Verzeichnis das was bei Active Directory sAMAccountName ist. Welche Auswirkungen haben diese Einträge genau?
Eigentlich verstehe ich die Einträge so, dass sie eindeutig sein müssen. Das Problem ist, dass die das in unserem Verzeichnis aber nicht sind. Wir haben z.T. doppelte Benutzernamen, jedoch in anderen Organisationseinheiten.
Deswegen hatte ich 'mail' genommen, die sind eindeutig.

Grüße