Kategorie: Active Directory

  • Fehler bei der MS SQL Server 2022 Installation: „The RPC Server is unavailable“

    Die Installation von SQL Server 2022 kann in Umgebungen mit komplexen Netzwerkkonfigurationen zu Herausforderungen führen. Bei einer Installation ist beim Konfigurieren der Kontoinformationen für den SQL Server und den SQL Agent Dienst der Fehler „The RPC Server is unavailable“ und „The SQL Server service account login or password is not valid„, aufgetreten. Dieser Beitrag erklärt, wie dieses Problem in unserem spezifischen Szenario gelöst wurde.

    Problemstellung

    Während der Installation des SQL Server 2022 tritt beim Übergang zum nächsten Schritt des Installationsassistenten, in dem die Dienstkontoinformationen für den SQL Server und den SQL Agent konfiguriert werden, ein Fehler auf. Die Fehlermeldungen lauten „The RPC Server is unavailable“ und „The SQL Server service account login or password is not valid„. Obwohl die zweite Meldung suggeriert, dass Benutzername oder Passwort des Dienstkontos nicht korrekt seien, ist dies tatsächlich irreführend, da die Credentials korrekt sind.

    Ursache des Problems

    Die Ursache für den Fehler liegt in der Netzwerkkonfiguration, speziell im Zusammenhang mit der DNS-Konfiguration. In unserem Fall verwendet das Active Directory einen sogenannten Disjoined Namespace, bei dem die Member-Server einen vom AD-Namen unterschiedlichen DNS-Suffix haben. Der SQL Server Installer versucht offenbar, die Domäne nicht mit einem vollqualifizierten Domänennamen (FQDN) zu erreichen, sondern nur mit einem Hostnamen. Das Anhängen des DNS-Suffix des lokalen SQL Servers scheitert daher aufgrund des Disjoined Namespace.

    Lösung des Problems

    Eine erfolgreiche Lösung wurde nach eingehender Recherche auf der Webseite https://deibymarcos.wordpress.com/2016/04/06/sql-server-set-up-error-the-rpc-server-is-unavailable/ gefunden. Der entscheidende Tipp war, dass die DNS-Suffix-Liste vollständig konfiguriert sein muss.

    Um das Problem zu beheben, wurden die folgenden Schritte durchgeführt:

    1. Überprüfung der DNS-Einstellungen auf dem Server, auf dem SQL Server 2022 installiert werden soll.
    2. Hinzufügen des DNS-Suffix der Active Directory-Domäne zu den DNS-Einstellungen des Servers.
    3. Neustart des Installationsvorgangs für den SQL Server 2022.

    Nach der Konfiguration der DNS Search Suffixe verlief der MS SQL Installationsprozess ohne weitere Probleme.

  • Bei Office 365 das Ablaufen der Benutzer-Passwörter deaktivieren (Set up office 365 user passwords to never expire)

    Als Standardeinstellung werden bei Office 365 Accounts die Passwörter nach 90 Tagen ungültig bzw. laufen aus und müssen neu gesetzt werden. Wenn man diese Zeit als zu kurz ansieht oder den Zwang, die Passwörter neu zu setzen ganz abschalten will, muss man die Windows PowerShell zu Hilfe nehmen.

    Um sich mit der Powershell mit seinem Cloud ActiveDirectory zu verbinden, braucht man zwei Voraussetzungen:

    1. „MS Online Sign In Assistant“ Download
    2. Install the Powershell Azure AD Module Download

    Sind beide Voraussetzungen installiert, gibt man folgende Befehle in der Powershell Eingabeaufforderung ein:

    Import-Module MSOnline

    #Hier gibt man seine Administrator-Zugangsdaten ein, mit dem man Office 365 administriert
    $msolcred = get-credential

    #Verbindungsaufbau zum Active Directory seines Office 365 Accounts
    connect-msolservice -credential $msolcred

    #Zu bearbeitendes Userobjekt ermitteln
    $user=Get-MsolUser -UserPrincipalName „user@domain.tld

    # Setzen der PasswordNeverExpires Eigenschaft aus True
    $user | Set-MsolUser -PasswordNeverExpires $true

    Um die Einstellungen zu kontrollieren, kann man sich alle Eigenschaften des Benutzerobjekts anzeigen lassen:

    Get-MsolUser -UserPrincipalName User@Domain.tld | fl

    Weitere Infos

  • Zusätzliche E-Mail-Adressen zu Office 365 Exchange Online-Kontakten hinzufügen

    In der Office 365 Web-Administration kann man für Exchange Online-Kontaktobjekte nur eine E-Mail-Adresse konfigurieren. Möchte man zusätzliche E-Mail-Adressen angeben, muss man dies über die Powershell erledigen.

    Weitere E-Mail-Adressen für Kontaktobjekte können nützlich sein, um beliebige Weiterleitungen von E-Mail-Adressen an externe Adressen zu konfigurieren. E-Mails an alle weiteren E-Mail-Adressen von Kontaktobjekten werden an die primäre E-Mail-Adresse des Kontaktobjekts weitergeleitet.

    Vorgehensweise:

    Set-ExecutionPolicy RemoteSigned

    #Hier Benutzername und Passwort des administrativen Office 365 Accounts eingeben
    $UserCredential = Get-Credential 

    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

    Import-PSSession $Session

    #Optionales Hinzufügen eines neuen Kontaktobjekts

    $myContact=New-MailContact -Name „Max Mustermann“ -DisplayName „Max Mustermann“ -ExternalEmailAddress „max@mustermann.de“

    #Alternativermitteln eines bestehenden Kontaktobjektes

    $myContact =Get-MailContact -Identity “ Max Mustermann „

    #Hinzufügen der zusätzlichen E-Mail-Adressen zu dem Kontaktobjekt

    $myContact |Set-MailContact -EmailAddresses „SMTP:mail@test.de“

    #Kontrolle, welche zusätzlichen E-Mail-Adressen einem Kontakt zugewiesen wurden

    Get-MailContact -Identity „Max Mustermann“|select -ExpandProperty EmailAddresses

    #Trennen der Remote-Powershellverbindung

    Remove-PSSession $Session

    Weitere Informationen: Adding multiple Email addresses to mail contacts in Office 365

  • Active Directory LDAPS Zugriff mit ldapsearch unter Linux

    Mit dem Befehl ldapsearch kann man LDAP-Abfragen an einen LDAP-Server stellen und damit Verzeichnisinformationen ermitteln. Da die meisten Active Directory keine anonyme Anfragen erlauben, benötigt man ein Dienstkonto im Active Directory, das die nötigen Rechte für die erforderlichen LDAP-Anfragen besitzt.

    Der grundsätzliche Syntax einer LDAP-Abfrage mit ldapsearch lautet:

    ldapsearch -x -D „USERNAME@ADDOMAIN“ -w „DIENSTKONTOPASSWORT“ -b „searchbase“ -H LDAPSERVERURL „FILTER“ PROPERTY1 PROPERTY2 PROPERTYN

    -x = Use simple authentication instead of SASL
    -D = Use the Distinguished Name binddn to bind to the LDAP directory
    -w = Use passwd as the password for simple authentication
    -b = Use searchbase as the starting point for the search instead of the default
    -H = Specify URI(s) referring to the ldap server(s)

    FILTER = Die eigentliche LDAP-Abfrage
    PROPERTYX = Propertys der Objekte, die im Ergebnis angezeigt werden sollen

    Beispiel:

    ldapsearch -x -D „ldap@domain.local“ -w „badladappasswort“ -b „dc=domain,dc=local“ -H „ldaps://dc.domain.local:636“ „(sn=USERNAME)“ description dn

    Obige Abfrage ermittelt die description und den dn des Accounts USERNAME.

    Um bei ldapsearch nicht immer alle Parameter für die Verbindung angeben zu müssen, kann man in seinem Homeverzeichnis eine Datei namens .ldaprc anlegen.

    #Beispielinhalt:
    URI ldaps://dc.domain.local:636 #Liste mit LDAP Servern (Parameter -H)
    BASE dc=domain,dc=local #Search Base DN (Parameter -b)
    BINDDN ldap@domain.local #Dienstkonto für die LDAP Verbindung (Parameter -D)
    TLS_CACERT /etc/ssl/certs/rootca.pem #CA Zertifikat der Root CA des DC SSL Zertifikats

    Um nicht jedes Mal das Passwort für die Verbindung LDAP-Verbindung angeben zu müssen, kann man eine Datei mit dem Passwort erstellen und diese bei ldapsearch mit der Option -y angeben.

    Die Passwortdatei muss man zwingend ohne Steuerzeichen erstellen. Dies gelingt z.B. mit dem Befehl echo und dem Parameter -n.

    echo -n DIENSTKONTOPASSWORT > .ldappasswd

    So sieht nun der verkürzte Syntax der ldapsearch Anfrage aus:

    ldapsearch -x -y ./.ldappasswd „(sn=USERNAME)“ description dn

  • ldapsearch -y schlägt mit der Fehlermeldung „ldap_bind: Invalid credentials (49)“ fehl

    Bei dem Programm ldapsearch kann man mit der Option -y eine Datei angeben, aus der ldapsearch das Passwort für die Verbindung zum LDAP Server ausliest. Obwohl das Passwort in der Datei korrekt war, lieferte ldapsearch immer den Fehler „ldap_bind: Invalid credentials (49)“. Nach einigem Suchen fand ich die Lösung.

    ldapsearch kommt nicht damit zurecht, wenn ein Zeilenendzeichen oder Zeilenumbruch die Zeile in der Passwortdatei begrenzt. Diese werden bei der Authentifizierung als Passwortbestandteil gesehen, was die Authentifizierung natürlich fehlschlagen lässt.

    echo PASSWORT > .ldappasswd

    erzeugt eine Datei, die die Fehlermeldung “ldap_bind: Invalid credentials (49)” liefert, wenn man sie mit der ldapsearch -y Option benutzt, obwohl PASSWORT das korrekte Passwort für die LDAP Verbindung ist.

    Die Lösung für das Problem ist das Löschen der Steuerzeichen mit dem tr Kommando.

    echo PASSWORT | tr -d ‚\n\r‘ > .ldappasswd

    Alternativ kann man auch die -n Option (do not output the trailing newline) bei dem Echo Befehl benutzen:

    echo -n PASSWORT > .ldappasswd

    Nun funktioniert die Datei mit der ldapsearch Option -y ohne Fehlermeldung.