SBS 2008 / Exch. 2007 – Fehler 451 4.4.0 Primary target IP address responded …

Hallo zusammen,

heute hatte ich ein Problem mit einem SBS 2008, welcher nach dem Wochenende keine Mails mehr via Smarthost versenden wollte.

Im der Warteschlangenanzeige des Exchange liefen nach und nach die Mails auf mit dem Fehler:

451 4.4.0 Primary target IP address responded with: „421 4.2.1 Unable to connect.“ Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.

 

Zuerst die üblichen Verdächtigen geprüft:

  • Internetverbindung vorhanden?
  • Ports nicht geblockt?
  • DNS funktioniert auch fehlerfrei?

 

Alles schien zu passen. Internet war verfügbar, alle (relev.) Ports waren offen und der DNS funktionierte auch (auch mal ein ipconfig /flushdns) brachte keine Besserung.

Nach dem Motto „Reboot-tut-gut“ wurde auch das versucht – auch ohne Erfolg.

Nach ca. 1h dachte ich, komm, gebe nochmals die Daten für den Smarthost ein – auch kein Erfolg.

Erst als ich für den SmartHost andere Anmeldedaten verwendete, funktionierte es plötzlich wieder – seltsam, die „alten“ Anmeldedaten waren nach wie vor gültig und auch korrekt.

Nunja, manchmal muss man nicht alles verstehen …

 

Ubuntu 14.04 und das ProFTPD Daemon Problem

Nachdem ich unseren produktiven FTP-Server von Ubuntu 12.04 LTS nun auch 14.04 LTS upgedated habe,

habe ich feststellen müssen, das immer wieder am Wochenende der ProFTPD Daemon gekillt wurde.

Im Logfile des ProFTPD stand lediglich nachfolgende Meldungen:

  2014-09-14 06:50:14,392 proftpd[13198]: ProFTPD killed (signal 15)
  2014-09-14 06:50:14,392 proftpd[13198]: ProFTPD 1.3.5rc3 standalone mode SHUTDOWN

Nach einer ersten Analyse kam ich, anhand der Uhrzeit, auf den Logrotate als möglichen Übeltäter.

Dieser führt, nach dem Aufräumen der Logfiles, einfach einen Restart des ProFTPD Daemon’s aus.

Anscheinend liegt aber genau darin das Problem – hier kommt es wohl zu einem Timing Problem – sprich: es geht zu schnell!

Das Problem lässt sich auch ohne Logrotate reproduzieren – einfach den Restart mehrfach ausführen.

Schon nach kurzer Zeit ist nach dem Restart der Daemon inaktiv!

Damit das Problem nun gelöst wird, habe ich das Script /etc/init.d/proftpd so angepasst, das beim Restart eine Pause von 3 Sekunden den Vorgang zwischen Stop und Start etwas bremst.

Auszug aus dem angepassten Script:

…

  start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile "$PIDFILE"
   if [ $? = 0 ]; then
      log_end_msg 0
      # Pause von 3 Sek. wg. Timing Problem
      sleep 3
   else

…

Damit sollte das Problem nun nicht mehr auftauchen.

Hinweis: Den sleep Befehl nicht direkt unter die Zeile „start-stop-daemon …“ packen, sonst läuft die darunter befindliche Statusabfrage nicht mehr auf den Stopbefehl sondern auf den sleep Befehl.

Viel Spass nun beim Testen …

Active Directroy – Kennwortrichtlinie – Unterschied zwischen „konfigurieren“ und „nicht definiert“

Es gibt wahrscheinlich tausende Einträge über Google bzgl. dieses Thema’s, aber ich hatte heute wieder einen Fall – daher dieser Niederschrieb 😉

In einem Active Directroy (AD) von Windows lassen sich ganz bequem Kennwortrichtlinien erfassen und einstellen.

Allerdings muss man hierbei zwingend unterscheiden zwischen „konfigurieren“ und „nicht definieren“.

In meinem Beispiel dreht es sich um einen Windows Server 2012 R2 als DC und einen Exchange 2013 (auf einem sep. Win2012R2).

Als die 2012er Domäne installiert wurde, hatte die Default-Domain-Policy die Grundeinstellung, das die AD-Passwörter nach 42 Tagen auslaufen und geändert werden müssen – das war mir zu kurz.

Leider habe ich dann darauf hin die beiden betroffenen Punkte auf „nicht definiert“ geändert und dachte, das dies korrekt sei – leider falsch.

Die Richtlinie sah nun wie folgt aus:

falsche Kennwortrichtlinie

Die hatte leider zur Folge, das die Standardeinstellungen des AD’s von 42 Tagen griffen, da die Richtlinien ja nicht definiert wurden ;-(

Nach ca. 35 Tagen wurde ich wieder erneut aufgefordert, mein Kennwort erneut zu ändern – hä?

Nunja, nach genauerer Überlegung kam mir dann, das ich die Richtlinie falsch konfiguriert hatte.

Nach meiner Änderung sah die Richtlinie wie folgt aus:

richtige Kennwortrichtlinie

Nun war die Einstellung korrekt, d.h. das Kennwort läuft nun nicht mehr ab.

 

Vielleicht hilft es ja dem ein oder anderen auch mal, wenn er über so etwas stolpert …

Viel Spass beim Testen …

 

MySQL root Passwort ändern

Das ändern des Passwortes vom „root“ in der Kommandozeile ist eigentlich ein ziemlich simpler Vorgang.

Da ich mir den Befehl aber selber nie merken kann schreibe ich ihn hier auf:

Mit folgenden Befehl auf der MySQL Serverkonsole anmelden

mysql -u root -p

Die Datenbank mysql auswählen

use mysql;

Passwort mit folgendem Befehl ändern (dein-neues-passwort durch ein entsprechendes Passwort ersetzten):

update user set password=PASSWORD('dein-neues-passwort') where User='root';

Anschließend ein Flush Privileges durchführen und die MySQL Konsole beenden:

flush privileges;
quit

 

Fertig 😉

Ubuntu und proftpd Daemon – Login Problem

Heute hatte ich leider ein Problem, welches mich fast zur Weisglut gebracht hat.

Es sollte dabei ein SLES 10 Server durch einen Ubuntu 12.04 Server ersetzt werden.

Darauf lief u.a. auch der FTP-Daemon proftpd.

Nachdem die User sowie die Daten korrekt übernommen wurde, konnten sich jedoch die FTP-Benutzer leider nicht anmelden.

Bei jedem Anmeldeversuch kam folgendes, obwohl die User korrekt eingerichtet waren:

530 Login incorrect.

Grund war nun, das beim „alten“ System in den Users (/etc/passwd) als Login Shell /bin/false eingetragen war.

Ubuntu Standard kennt diese Shell aber nicht!

Hierzu musst du in der Datei /etc/shells den Eintrag /bin/false ergänzen.

Nach einen Neustart des FTP-Deamon’s klappt’s dann auch mit dem Login.

Subversion : Backup & Restore

Da ich vor kurzem ein Subversion System aufgesetzt habe, müssen natürlich 2 wichtige Faktoren funktionieren: Backup & Restore

Um ein Subversion Repositorie zu sichern, muss für jedes Repository folgendes gemacht werden:
$ svnadmin dump /pfad/zum/reponame > /backup/reponame.dump
$ scp -rp /backup/reponame.dump user@server.domain.com:/backup/

Um ein Backup zurückzusichern (restore) muss zunächst ein entsp. Repositorie erstellt werden:
svnadmin create /pfad/zum/reponame
Anschließend kann nun das Backup eingelesen werden:
svnadmin load /pfad/zum/reponame < /backup/repo1.dump

Viel Spass damit.

wipefile in neuer Version erschienen

Damit eine Datei sicher gelöscht ist, reicht es nicht nur aus, die gelöschte Datei aus dem Papierkorb zu löschen.

Erst wenn eine Datei überschrieben ist, werden auch die dafür verwendeten Datenblöcke „gelöscht“. Nach BSI Angaben ist die urspüngliche Datei erst nach dem 3. Überschreiben nahezu nicht mehr wiederherstellbar.

Als nützlichen Helfer nutze ich dazu bereits seit Jahren das Tool „wipefile“.

Auszug aus der Homepage:

[important]Mit WipeFile können Sie Dateien und ganze Verzeichnisse schnell und sicher löschen. Dazu überschreibt WipeFile die Dateien vor dem Löschen, um eine Wiederherstellung zu verhindern.

WipeFile kann Dateien mit 14 verschiedenen Methoden überschreiben. Dazu zählen z.B. zwei US Navy-Standards, die Standards des US Department of Defence, der US Airforce und der NATO.[/important]

Praktisch dabei ist auch, das die Software ohne Installation auskommt und als sogenannte „Portable App“ auch z.B. auf einem USB Stick direkt nutzbar ist.

Die vor kurzem erschienene Version 2.3 könnt ihr hier herunterladen.

Viel Spass damit

PS: Solltest du mal eine ganze Festplatte löschen wollen, nutze dazu einfach das Tool „wipedisk“ …

 

Windows 7 – Fehler bei der Anmeldung mit dem Benutzerprofildienst

Der heutige Tag startete leider nicht ganz so einfach. Ein Kollege kommt nach 2 Wochen Urlaub wieder zurück, startet sein Laptop und meldet sich an seinem Windows 7 an – zur Überraschung findet er nach der Anmeldung ein komplett neues Profil wieder.

Windows zeigt zunächst lediglich den Hinweis, das ein temporären Profil angemeldet wurde. In der Windows Ereignisanzeige fand sich folgendes: „Fehler bei der Anmeldung mit dem Benutzerprofildienst. Das Benutzerprofil kann nicht geladen werden“. Nach einer ersten Analyse war die Ursache dafür ein Update von Skype.

Folgendes hatte ich zunächst, leider erfolglos, versucht:

  • Anmelden als administrativer User (z.B. Administrator)
  • Umbenennen der vorherigen Userprofils z.B. C:\Users\<NormalerUser>.defekt
  • erneute Anmeldung des Users <NormalerUser>  (erstellt wieder das Userverzeichnis)
  • Anmelden als administrativer User (z.B. Administrator)
  • Löschen des (neuen und leeren) Profilverzeichnisses C:\Users\<NormalerUser>
  • Umbenennen der Verzeichnisses C:\Users\<NormalerUser>.defekt nach C:\Users\<NormalerUser>
  • erneute Anmeldung des Users <NormalerUser>
  • mit Viel Glück ist das Profil ggf. wieder gerettet (bei mir leider nicht)

 

Leider half dies bei meinem Problem nicht – der User wieder nach wie vor mit einem temporären Profil angemeldet. Nachfolgende Schritte halfen jedoch wieder zu einem funktionierenden Profil.

  • Anmelden als administrativer User (z.B. Administrator)
  • Öffnen der „Systemsteuerung“ -> „System“ -> „Einstellungen ändern“
  • anschließend auf „Erweitert“ -> „Benutzerprofile“ -> „Einstellungen“
  • wähle nun das Profil aus, welches gelöscht werden soll und lösche es
  • Öffne nun den Registrierungseditor (Start -> Suchfeld -> regedit)
  • Wechsle in der Registry auf folgenden Unterschlüssel:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
  • Wähle nun die SID des Users aus, wessen Profil du gerade gelöscht hast. Lösche nn die SID.
  • erneute Anmeldung des Users <NormalerUser>. Nun wird ein frisches Userprofil erstellt
  • wieder anmelden als administrativer User (z.B. Administrator).
  • Kopiere nun noch den Inhalt des alten Profiles in das frische (oder benenne es um). Nach einer erneuten Anmeldung des Users <NormalerUser> sollte das alte Profil wieder verfügbar sein.

Weitere Informationen dazu findest du auch bei folgendem Microsoftlink.

Viel Glück beim Reparieren …

 

Verlängern eines StartSSL™ Free (Class 1) SSL Zertifikat

Achtung!

StartCom stellt ab 01.01.2018 keine SSL Zertifikate mehr aus!

Das in diesem Artikel beschriebene Verfahren ist somit hinfällig!

Weitere Infos unter https://www.small-blog.de/startcom-stellt-ab-2018-keine-zertifikate-mehr-aus/

 

-= Diese Beschreibung wurde im Dez. 2014 sowie im Dez. 2015 und im Nov. 2016 erweitert bzw. aktualisiert =-

Du nutzt ein kostenloses SSL Zertifikat von StartSSL.com ?

Das einjährige Zertifikat läuft (mal wieder 😉 ) in kurzer Zeit ab?

=> Hinweis: Nach dem derzeitigen Stand verlängert sich das Zertifikat um 3 Jahre (statt 1) und es lassen sich bis zu 10 (ja zehn!) Subdomains konfigurieren.

Kein Problem – mit folgender Anleitung lässt es sich verlängern und muss nicht neu erstellt werden.

 

  1. Das SSL Zertifikat von startssl.com ist ein kostenfreies Class 1 Zertifikat, welches jedes Jahr erneuert werden muss. 2 Wochen vor Ablauf wird man per Mail informiert. Aber es genügt leider nicht, nur das SSL Zertifikat zu verlängern – auch die E-Mail Validierung muss als erstes vorgenommen werden.
    (=> www.startssl.com => „Login“ => „Client Certificate Login“ => „Validations Wizard“ => „Email Validation“).
  2. Gib deine Mailadresse an
  3. Anschließend schickt euch StartSSL eine Mail mit einem Code, welcher auf dieser nachfolgenden Seite eingegeben werden muss.
  4. Ebenso muss auch das S/MIME Authentifizierungszertifikat erneuert werden. Solltest du dies nicht (rechtzeitig) erneuern, kannst du dich mit diesem Account nicht mehr einloggen. Neben deiner Mailadresse musst du auch noch unten den Punkt „Genereted by WebServer
  5. Die Webseite stellt nun eine Frage, welche unbedingt mit „JA“ beantwortet werden muss. Dann wird das Zertifikat im Browser installiert.
  6. Bitte auch der Hinweis – sichert das Browserzertifikat.
  7. Nun kommt das eigentliche SSL Zertifikat des Server’s dran, dies zu erneuern. Erstelle hierzu auf dem Server, auf welchem das derzeitige SSL Zertifikat aktiv ist, eine Zertifikatsanforderung (in meinem aktuellen Beispiel ist es ein SBS2008). Um dies durchzuführen, müssen folgende Schritte durchgeführt werden:
    – öffne die Windows SBS Console
    – klicke auf „Vertrauensw. Zertifikat hinzufügen“
    – wähle aus, das du ein Zertifikat erneuern möchtest (müsste die erste Option sein, wenn ich mich nicht täusche)
    – anschließend wird eine Zertifikatsanforderung erzeugt und angezeigt, welche du in eine Datei abspeichern kannst (und solltest).
    Hinweis: bei anderen Systemen (z.B. IIS, Apache, etc.) ist eine andere Vorgehensweise erforderlich – diese müsst ihr bitte selbst in Erfahrung bringen (oder Dr. Google fragen 😉 )
  8. Bevor nun das SSL Zertifikat angefordert werden kann, muss zunächst noch die „Domain Validation“ ausgeführt werden.  Wechsle hierzu auf „Validation Wizard“ -> Domain Validation -> deine root-Domäne angeben (keine Subdomain!) -> Mailadresse auswählen (meist die postmaster Adresse) -> Mail abwarten und -> Verification Code hinterlegen.domval01 domval02 domval03 domval04
  9. Ist die Anforderung wie oben erzeugt (meistens in eine Datei exportiert), kann das eigentliche Zertifikat beantragt werden.
  10. Die Subdomain in der ersten Zeile ist immer der Hauptbezug auf das Zertifikat. Unten muss dann noch der Punkt „Generated by Myself“ angeklickt werden und der generierte CRS reinkopiert werden. An dieser Stellte MEMO an mich selbst – du hast die autodiscover-DOM vergessen!!!
  11. Nach der Bestätigung kann man direkt die erzeugten, neuen Zertifikate herunterladen.
  12. Diesmal geht die Generierung sehr fix. Im Zipfile sind neben dem IIS Daten auch für z.B. einen Apache Daten hinterlegt.
  13. zip01
  14. Importiere nun zunächst das Zwischenzertifika „1_Intermediate.crt“
  16. Anschließend kann das eigentliche Zertifikat (wie in meinem Falle) im Exchange hinterlegt werden.
  17. Nun ist dein kostenfreies SSL Zertifikat erneuert – diesmal gleich um 3 weitere Jahre 😉

 

Enjoy it 😉