Customer SSO via LDAP und Childdomänen

[WolfgangMeisen]

Hi Folks,

ich habe hier mal was für die richtigen Cracks!

Installationumgebung: OTRS 3.2.3, IIS8, MS-SQL Server 2012 und Windows 2012.

In einer AD Forest sind eine Domäne mit dm Namen "xxxx.de" und mehrere Childdomänen mit der Notation "<land>.xxxx.de"
Die User dieser Domänen werden über die global catalog server des Forests aufgelöst. Es kann entweder der upn (userPrincipalName) oder der (msDS_PrincipalName) angesprochen werden. Der samaccountname fällt raus, der er den Domänennamen nicht mitführt. Die o.g. Attribute sind -wie gesagt - vom OTRS Server zu erreichen. (Kann man per LDAP Browser feststellen).

SSO funktioniert dann, wenn das Customer Mapping im Feld 'UserLogin' den samAccountnamen referenziert. Dem Feld 'CustomerID' ist der userprincipalName zugewiesen.

1.) Der Customer wird authentifiziert gegen den GC des AcrtiveDirectory.
2.) Da der Username erkannt und bestätigt wird, wird nun die Autorisierung durchgeführt.
Ist der Customer in der fürenden Domäne XXXX.DE wird er korrert autorisiert.
Wenn es aber mehrere User in verschiedenen Domänen des Forests mit dem gleichen Usernamen gibt, wird das falsche (erste?) OTRS - Konto angezogen.

Beispiel: wmeisen@xxxx.de meldet sich an, und kann seine Tickets einsehen (soweit sogut)
wenn nun wmeisen.land.xxxx.de sich anmeldet wird auch er korrekt authentifiziert aber auf das gleiche Konto referenziert, obwohl der nicht mit der ersten Person identisch ist. (Grund ist der gleiche samaccountName!)

Ich habe nun folgendes versucht:

1.) Umstellung auf den msDS-PrincipalName für den Userlogin und den CustomerID (Mapping und Anmeldung)
Hier habe ich festgestellt, das die Kundendaten in der CustomerListe richtig angezeigt werden, jedoch im Edit - Form keine Daten zu sehen sind. Hier schein es eine Feld-Einschränkung zugeben. Per Default werden die Customperdaten im Edit - Form angezeigt; auch dann, wenn die Referenzierung gegen ein LDAP /AD durchgeführt wird.

2.) Kerberos Authentifizierung. Hier sehe ich aber im Log immer noch den msDS-PrincipalName. Erwartet hätte ich den UPN.
--------------------------------------------------------
[Kernel::System::CustomerAuth::HTTPBasicAuth::Auth] User: XXXX\WMeisen Authentication ok (REMOTE_ADDR: 10.1.209.101, REMOTE_USER: XXXX\WMeisen).
[Mon May 27 10:57:48 2013][Error][Kernel::System::CustomerUser::SetPreferences][565] No such user 'XXXX\WMeisen'!
--------------------------------------------------------

Wenn jemand eine Idee oder sogar iene Lösung hat, dann her damit. ch denke es wird mehr Unternehmen betreffen, da die Meisten goßeren Häuser mehrere Domänen im Einsatz haben.

Danke
Wolfgang

[WolfgangMeisen]

Ich habe mittlerweile herausgefunden, das das Variablen- Mapping vom AD via IIS nach OTRS wie folgt aussieht.
Location Variablenname
Active Directory msDs.PrincipalName
IIS 7/ 8 LOGON_USER
PERL REMOTE_USER
Hier sollte nach Möglichkeit keine Änderung durchgeführt werden.
Das befriedigt mich aber nicht, weil es das Problem nicht löst. (Autorisierung via msDS-PrincipalName oder UserPrincipalName und nicht mit dem vermaledeiten samAccountName)

Ist da Irgendwer mit Ideen ?

[KlausNehrer]

Was steht in der config.pm bei AuthSyncModule::LDAP::UID?

[WolfgangMeisen]

Also:
meine config.pm sieht an er stelle wie folgt aus:

Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
$Self->{'Customer::AuthModule::LDAP::Host'} = \@dc;
$Self->{'Customer::AuthModule::LDAP::BaseDN'} = $BaseDN;
$Self->{'Customer::AuthModule::LDAP::UID'} = 'msDS-PrincipalName'; # AD user identifier domain\username
delete $Self->{'Customer::AuthModule::LDAP::GroupDN'}; # Gruppen werden derzeit nicht unterstützt.
#$Self->{'Customer::AuthModule::LDAP::GroupDN'} = $CustomerGroupDN; # siehe auch: Frontend::Customer::Groups = ja setzen
$Self->{'Customer::AuthModule::LDAP::AccessAttr'} = 'member';
$Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = $ServiceUserDN;
$Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = $ServiceUserPWD;
$Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'dn'; # for ldap posixGroups objectclass = uid)
# for non ldap posixGroups like Active Dirtectoy objectclass = dn)
#$Self->{'Customer::AuthModule::LDAP::UserLowerCase'} = 1; # wandelt den 'Username' in Kleinbuchstaben um
$Self->{'Customer::AuthModule::LDAP::Params'} = {
port => $ADPORT,
timeout => 120,
async => 0,
version => 3,
};

# -------------------------------------------------------------------------
# 2.) Autorisierung des Customers nach der Authentifizierung
# -------------------------------------------------------------------------
# Nachdem der User authentifiziert wurde, wird er gegen das AD autorisiert.
# Die Kundendaten werden zur Laufzeit aus dem AD gelesen und gegen den
# angemeldeten User getestet.
# Die AD-Daten werden der Anwendung zur Verfügung gestellt, ohne sie in der Datenbank zu speichern.
$Self->{CustomerUser} = {
Name => 'LDAP Backend f. Customer Autorisierung',
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
Host => \@dc,
BaseDN => $BaseDN,
SSCOPE => 'sub', # oder 'one'
UserDN => $ServiceUserDN,
UserPw => $ServiceUserPWD,
AlwaysFilter => '(&(!(ObjectClass=computer))(objectclass=person)(mail=*))',
SourceCharset => 'utf-8',
DestCharset => 'utf-8',
Params => {
port => $ADPORT,
timeout => 120,
async => 0,
version => 3,
},
},
CustomerKey => 'userPrincipalName', # Benutzername
CustomerID => 'msDS-PrincipalName', # Kundennummer
CustomerUserListFields => [ 'sn', 'givenname', 'mail'],
CustomerUserSearchFields => ['userPrincipalName', 'sAMAccountName', 'sn', 'givenname', 'mail', 'mobile', 'telephoneNumber' ],
CustomerUserSearchPrefix => '',
CustomerUserSearchSuffix => '*',
CustomerUserSearchListLimit => 10000,
CustomerUserPostMasterSearchFields => ['mail'],
CustomerUserNameFields => ['givenname','sn'],
AdminSetPreferences => 0,
Map => [
[ 'UserSalutation', 'Title', 'title', 1, 0,'var', , 0 ],
[ 'UserFirstname', 'Firstname','givenname', 1, 1,'var', , 0 ],
[ 'UserLastname', 'Lastname', 'sn', 1, 1,'var', , 0 ],
[ 'UserLogin', 'Username' 'msDS-PrincipalName', 1,1,'var', , 0 ],
[ 'UserEmail', 'Email', 'mail', 1, 1, 'var',0 ], #E-MAIL
[ 'UserCustomerID','CustomerID','msDS-PrincipalName',1,1,'var', ,0 ],
[ 'phone', 'Phone', 'telephoneNumber', 1, 0,'var', ,0 ],
[ 'mobile', 'Mobile', 'mobile', 1, 0,'var', ,0 ],
],
};

# -------------------------------------------------------------------------
# 3.) S i n g l e S i g n O n f ü r C u s t o m e r
# -------------------------------------------------------------------------
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth';
# ein möglicher Eintrag in der sysconfig zur Löschung des Domänennamens muss
# ausgetragen werden.
delete $Self->{'Customer::AuthModule::HTTPBasicAuth::Replace'};
delete $Self->{'Customer::AuthModule::HTTPBasicAuth::ReplaceRegExp'};

# If you use this module, you should use the following
# config settings as fallback, if user isn't login through apache ($ENV{REMOTE_USER})
$Self->{CustomerPanelLoginURL} = $CustomerPanelLoginURL;
$Self->{CustomerPanelLogoutURL} = $CustomerPanelLogoutURL;

[WolfgangMeisen]

Sorry, den letzten Eintrag habe ich etwas flott geschlossen:

mit dieser Customer Authentifizierung und Autorisierung bekomme ich im Customer Management folgende Darstellung:
Username = <Domain>\<loginname>
Name = Givenname, SN
E-Mail = <mailaccount>@<maildomain>
CustomerID = <Domain>\<loginname>
Last Logon = leer
Validity = Leer

in "Edit Customer" bleiben alle Felder leer.
Ich gehe davon aus, das der Username auf validität geprüft wird. Da er aber nicht dem UPN bzw dem samaccountName entspricht, wird der edit -mode verweigert.