ImapAuth Probleme

[asteini]

Hallo ihr Lieben,

wir haben die neue 6.14 auf unseren Systemen eingespielt. Die Authentifikation lief bei uns so ab, dass der Benutzer immer benutzername@contextdomain(da mehrere Mandanten) zum Anmelden eingeben musste. Aufgrund des Paramaters use_multiple=true in der Datei imaauth.properties wurde aber im Backen der IMAP-Loginname aus der Datenbank verwendet. In unserem Fall nur der Benutzername. Der Cyrus nahm dies intern an und alles klappte prechtig. Die neue Version scheint die ausgeschriebene Adresse zu uebergeben. Hat von euch jemand das Gleiche beobachten koennen. Ist es ein BUG oder neues Feature??

Gruss
Steini

[Martin Heiland]

Hallo Steini,

ich bin mir recht sicher dass es sich dabei um einen Bugfix handelt. Der Loginname aus der Datenbank sollte bei imapauth eigentlich nie genutzt werden da die Anmeldung ja gegen IMAP geht und nicht gegen die Datenbank. Das hatte zur Folge, dass zwar der Login am IMAP fehlschlug (Zugriff auf die Mailbox), aber der Login in den OX Account trotzdem möglich war. Das Modul nutzt nun die Daten, die der Benutzer beim anmelden im Login Fenster angibt. Ob der volle Login (user@domain.tld), oder nur der Benutzername für die Anmeldung verwendet wird, bestimmt der Parameter USE_FULL_LOGIN_INFO.
Wenn explizit angegeben wird dass es sich um ein multidomain System handelt, ist es imho nur sinnvoll auch die volle Domain zur Anmeldung zu nutzen.

Gruß

[asteini]

Hallo Herr Braun,

Ein Fix ?! Ich verstehe nicht ganz. Also dass der ImapAuth Vorgang gegen den IMAP Server und nicht Datenbank läuft war mir bewusst. Aufgrund der Multidomain Konfiguration ist die Angabe der Domain bei dem WEB Frontend vom OX zwingend erfortderlich. Sonst klappt ja der Authvorgang gar nicht. Unabhängig vom Auth Verfahren (DB,LDAP oder IMAP). Ich verstehen nicht wie da der OX LOGIN möglich war. Wir hatten jedenfalls bei multi context immer die contextid oder contextname mit eingeben müssen.

Mithilfe der "imaplogin" Spalte in der Tabelle "user" und dem o.g. Parameter(use_miltuple) konnten wir den Cyrus ohne multidomains auslegen und uns die Umkonfiguration von ca. 300 Outlook Clients ersparen. Die Nutzer geben bei der WEB Anmeldung "user@domain.ldt" ein - systemintern wurde aber der Benutzername entsprechend der "imaplogin"- Spalte genommen und dem IMAP Server gereicht. Ich sehen einfach die Sicherheitslücken nicht. Die Clients verwenden intern ebenfalls nur den Benutzernamen. Der Authvorgang landete ja immer beim Imap Server, nur mit einem anderem Namen.

Momentan sehen wir keine andere Möglichkeit als den Cyrus auf "user@domain.ldt" zu trimmen und die Clients umkonfigurien. Es sei den, die Community hat eine Hackentrick parad.

NACHTRAG:
Wenn man vom Parameter USE_FULL_LOGIN_INFO und unserer Situation ausgeht, dann muss dieser auf "False" stehen. Damit nur der "Username" zum IMAP übertragen wird. Beim login gebe ich "username@domain.tld" Siehe da...

INFO: Imap authentication for user username successful on host localhost:143

nur direkt danach

SEVERE: CTX-0010 Category=1 Message=Cannot find context "defaultcontext". exceptionID=1256024877-17

Logischerweise - die Datenbank hat diesen Context nicht, das wir mehrere Contexte verwalten. Der Nutzer befindet sich im Context 4. Wie kriege ich diese der Groupware beigebracht??


Gruss
Steini

[Martin Heiland]

Hallo,

du kannst mehrere Kontextmappings pro Kontext zuweisen. Der Name "defaultcontext" ist reserviert und wird genutzt wenn z.b. nur der Benutzername angegeben wird.

Das Problem mit der vorherigen Lösung war, dass die Spalte "imapLogin" seit 6.10 deprecated ist da wir die Verwaltung der mailaccounts umgestellt haben - um mehrere Accounts pro User zu ermöglichen. In einer späteren Version von OX wird diese Spalte nicht mehr genutzt und eine Änderung von --imaplogin hätte keinen Einfluss auf imapauth da es die veraltete Spalte benutzt.

Weiterhin ist die Konfiguration "USE_MULTIPLE" für den Fall gedacht, dass die IMAP/SMTP Logindaten für den Benutzer nicht in der Konfigurationsdatei für imapauth liegen, sondern für jeden Benutzer in der Datenbank festgelegt wurden. Früher wurde auch der Benutzername aus der Datenbank gelesen. Der Benutzername hat mit der Konfiguration des IMAP/SMTP nichts zu tun, daher wurde er entfernt. In der Konfigurationdatei steht es noch "falsch", das wird aber korrigiert. Wenn nötig können wir eine weitere Konfiguration für die Quelle des Benutzernamens einführen.

Gruß

[asteini]

Verzeih meine Unwissenheit ... ehrlich. Darf ich fragen, wie ich Kontextmapping erstelle? Wie kann ich der Datenbank beibringen ,dass der Benutzer während der Authentifizierung z.b im Context 1(domain.tld) liegt. Ich meine, der Benutzer ist schon im Context 1, so ist es ja nicht. Der Nutzer wurde so angelegt! Bei der Anmeldung gebe ich auch den contextname "domain.tld" oder @1 an! Nur dann kommt er mir mit dem "Defaultcontext"

NACHTRAG
Um die Sache zu steigern ... wir führen die User aus dem LDAP mittels OXLDAPSYNC in die Groupware. Der UID dort entpsricht "username". Ich würde auch gerne gegen LDAP authen, nur da kann man keine multiple DNs betreiben.


Sorry
:-)

[asteini]

Nur fürs Verständnis,

Also da wir MutliContext in der Groupware betreiben, müssen wir logischerweise mit username@contextmapping arbeiten. Damit in der DB der Benutzer gefunden werden kann. Mit Kontextmapping meinst du sicherlich -z.b. zum Context 1 der Domainname "haumichblau.de", oder?.
Wenn ich also im Backend einen Mailserver laufen hab, der "Virtualdomains" nicht beherscht und die Mailbox Authentifizierung nur anhand eines usernames erfolgt, funktioniert die Anmeldung mit imapauth nicht mehr. Verstehe ich dies richtig??

[Martin Heiland]

Hi,

Loginmappings kannst du mit changecontext -L <deinmapping> anlegen. Es wird in Kürze ein Update von imapauth geben dass dein Problem behebt. Der eigentliche Fehler war, dass der login name ausschließlich aus der Datenbank gelesen wurde, und nicht aus der Konfiguration des Mail Moduls.

Gruß

[asteini]

Wann ist mit dem Update zu rechnen? Bei uns brennts an
... aber unabhängig davon ... Martin VIELEN VIELE DANK für sofortige und vor allem qualifizierte Unterstüzung!!!

NACHTRAG: Wir sitzen auf OpenSUSE 11.1 und dessen Repositorys

Gruss
Steini

[Martin Heiland]

Hi, wenn es so dringend ist - du könntest versuchen das 6.12er imapauth wieder einzuspielen. Ein Versuch ist es wert.

Gruß

[asteini]

Ich glaube die Paketabhängigkeiten werden mir einen Strich durch die Rechnung machen. Ich probiere es gerade ...

[Carsten Hoeger]

einfach so lange mit rpm -Uhv --nodeps installieren.

[asteini]

ich kriege das Paket open-xchange-authentication-imap-6.12.0.0-8_8.1.noarch.rpm bei OpenSUSE nicht mehr. Mit Zypper Downgrade geht ja auch nicht. Hat da jemand einen Rat?

NACHTRAG:

Ja ... habs gefunden

http://dl2.foss-id.web.id/opensuse/repositories/server:/OX:/ox6/openSUSE_11.2/noarch/

[asteini]

Ja ... wir sind wieder dabei!

Als Erstes mit

rpm -ev --nodeps open-xchange-authentication-imap-6.14.0.0-5_5.1.noarch

das aktuelle Paket deinstalliert und danach wie oben schon von Carsten Hoeger empfohlen mit

rpm -Uhv --nodeps open-xchange-authentication-imap-6.12.0.0-8_8.1.noarch.rpm

das alte Paket installiert. Zuvor habe ich das Paket Hier bezogen.

Die Anmeldung hat gefunzt. Hoffe natürlich, dass es bald möglichst einen Update gibt. Bin gespannt ob ich das System dann ohne Weiteres updaten kann.

Möchte nochmal die Gelegenheit nutzt um allen Beteiligten DANKE SCHÖN zu sagen. IHR SEID SUPER!

Danke und Gruss
Steini

[Martin Heiland]

Hi,

das Update wurde gerade veröffentlicht.

Gruß

[asteini]

Kras, auch im OpenSUSE 11.1 Repo ?