Dukel

Anmelden gibts als Trigger für Geplante Tasks. Da brauchst du kein Ereignis. Standby / Ruhezustand müsste ich heraussuchen, findet man aber sicher bei google.

Schonmal den Server neu gestartet? Gibt es Fehlermeldung im Eventlog oder bei der Software? Wurde am Server irgendwas geändert oder nur an de Clients?

Nein. Wir können diese Kiste eben nicht ausklammern, da diese mit involviert ist. Wenn diese Kiste nicht als Smarthost (temporär zum testen) konfiguriert wird, am ziel das annehmen von unbekannten Empfängern verboten wird und du das ganze nochmal testest, dann kann man die Kiste ausklammern. Wenn du danach die Kiste als Smarthost wieder einträgst wirst du sehen, das sich das verhalten ändert. http://www.mcseboard.de/topic/199395-exchange-2007-schickt-keine-ndrs-obwohl-erlaubt/?do=findComment&comment=1241172 http://www.mcseboard.de/topic/199395-exchange-2007-schickt-keine-ndrs-obwohl-erlaubt/page-2?do=findComment&comment=1241279 Wenn die Linux Kiste keinen Einfluss hätte wäre das verhalten immer gleich.

Es ist NO_TRUNCATE http://www.sqlskills.com/blogs/paul/disaster-recovery-101-backing-up-the-tail-of-the-log/

Willst du nur die oben genannten Themen in das Sicherheitskonzept aufnehmen? Wie ist es mit z.B. Passwortrichtlinien; Provisioning (User zu- und Abgänge); Benutzerrechte; Administrative Konten; Serversicherheit; Physikalischer Zugriff; ... Wenn man es sehr umfangreich machen will kann man Themen wie Backup oder Verfügbarkeiten auch aufnehmen.

Du kannst auch mit einem Trigger arbeiten und das eine Feld automatisch ändern, wenn im anderen etwas eingetragen oder geändert wird.

Was ist das für ein Ticket Tool und gibt es keine AD Authentifizierung?

Wozu willst du das machen? Du kannst bei Abfragen auf beide Tabellen zugreifen und dir die Fehlenden Daten aus der anderen holen.

Ja es werden die Transaktionsprotokolle genutzt. Auch im normalen Betrieb werden Daten nicht sofort in die Datenbankdateien geschrieben sondern auch erst in die Transaktionsprotokolle und später in die Datenbankdateien.

Evtl. lässt sich das mit einer 3rd Party Software lösen, die das Privisioning übernimmt und die unterschiedlichen Datenquellen pflegt.

Und was sagt der Sendeconnector? Ich könnte wetten der eine hat die Linux Kiste als Smarthost und der andere nicht. Haben die beiden Exchange Server etwas miteinander zu tun?

Kommt dieser NDR vom Exchange oder von einem anderen Server? Sind diese beiden Server unterschiedlich konfiguriert, was Sende Connector angeht? Nutzt einer die Linux Kiste als Smarthost und der andere nicht? Wenn Exchange die Mail an die Liste Kiste weiterleitet und diese überprüft, ob der User existiert kann nur die Linux Kiste einen NDR generieren. Exchange weiß von der Mail nichts mehr. Sind die die SMTP Grundlagen bewusst?

Dann musst du die Linux Spamcheck Kiste so konfigurieren, dass dieser einen NDR an den Absender schickt. Im Exchange kannst du das dann nicht, wenn Exchange die Mail los wird.

Das hat Robert schon mitgeteilt: http://www.mcseboard.de/topic/199395-exchange-2007-schickt-keine-ndrs-obwohl-erlaubt/?do=findComment&comment=1241155

Gibt es bei euch solche Probleme das GPO's nicht angewandt werden?

Du brauchst bei FTP immer min. 2 Ports.

Ich meinte nur, wenn es schon am aufteilen von Strings hängt. Wie lange arbeitest du schon an dieser Applikation? Hatte hier schon mehrere Threads von dir zu dem Thema gesehen.

Mein Tipp: Lass dir das ganze von einem Softwarehaus Programmieren.

Was passiert, wenn du den Listenport auf 4711 lässt und die Port Range auf 4712-4712 konfigurierst (Firewall natürlich anpassen)?

Versuche einmal eine größere Port Range und nicht nur einen Port. EDIT: Ach ja. Evtl. musst du einen anderen Port bei Listen als bei der Port Range eintragen. Versuche Listen: 4711 und Passive Port Range 4712-4712 (und wenn das nicht geht eine Range z.B. 4712-4799)

Du kannst dich auch Passwortlos an PHP anmelden. http://php.net/manual/de/book.kadm5.php Dann bekommst du auch deine Servervariable gefüllt und musst nicht mit Cookies pfuschen.

Du kannst deine eigene Identität per SQL Statement abfragen: http://blog.sqlconcepts.co.nz/2011/07/who-am-i.html Was passiert, wenn der User in den Formularen einen anderen User einträgt? Wieso Authentifizierst du dich nicht mit der Webapplikation und nutzt diese Authentifizierung?

Es gibt ja nicht nur BCS (wobei man das mit der Claims Authentifizierung dann so machen muss, da Kerberos Constraint Delegation nicht mehr geht). Ich finde es erhöht die Sicherheit, wenn man das ganze in einem gescheiten Konzept umsetzt. Oft hat ein DB User, welcher viel zu viel Rechte besitzt (z.B. DB Owner) und wenn man (wie auch immer) an diesen User kommt kann man mehr machen als wenn man nur mit den User Daten an die DB kommt und dort ganz wenig Rechte besitzt. Wenn man einen DB Server hacken kann ist es eh ein prinzipielles Problem. Ich denke nicht, dass das grundsätzlich mit durch gereichten Anmeldungen zu tun hat. Aus dem PHP Umfeld kenne ich das auch, dass man einen DB User hat und dort ist es oft auch so, dass dessen Credentials unverschlüsselt im FileSystem liegen und dort ist es in jedem Fall sicherer wenn nirgends Credentials gespeichert werden.

Das kann nur der Empfänger. Sobald die Mail deinen Exchange verlassen hat hast du keine Kontrolle mehr darüber. Sinnvoller wäre, dass der Empfänger das annehmen von allen Empfängern unterdrückt. Kannst du deinen Test mit einer anderen Domäne einmal testen.

Was für Formulare denn? Ich hoffe es sind keine Anmeldungen für anderen Applikationen. PHP kennt auch den Authentifizierten User: http://php.net/manual/de/reserved.variables.server.php echo $_SERVER['PHP_AUTH_USER']; EDIT: Es spricht prinzipiell nichts dagegen sich an einer DB zu authentifizieren. Dabei kann man direkt an der Quelle Rechte vergeben und muss das nicht in einer Zwischenschicht (auf dem Applikationsserver) machen. Mit SharePoint gibt es auch die Möglichkeit mit einem User auf externe Datenquellen (u.A. SQL Server) zuzugreifen. Dies wird mit Kerberos Delegation umgesetzt.