Change Your AD Password easily via OWA

In many environments, Microsoft Active Directory is used to manage users, their roles and permissions and of course their passwords.
When you have set up an  Exchange Server as well, you may want to provide your users with the Outlook Web App. Here also users without Microsoft Windows are able to tune their mail settings and their Active Directory passwords, too.
Sometimes the method may not be completely clear, so please feel free to use this following guide whenever you need to.
Disclaimer: The screenshots display a German OWA and my GIMP skills are, well, improvable.
First you need to login. Please don’t forget to add your domain name.

Then find the small gear and click it.

Use the drop down and navigate to “change password”

You’ll now be prompted to enter your old (1) and your new password twice (2,3). Hit “Save”(4) for using your new password and you’re done!

Tim Albert
Tim Albert
System Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere...

Icinga Director: Active Directory User als Kontakte importieren

Heute erklären wir euch im Schnelldurchlauf wie man Kontakte aus dem Active Directory in den Icinga Director importiert.
Als Grundlage konfigurieren wir das Active Directory als Ressource im Icinga-Web 2
# vi /etc/icingaweb2/resources.ini
[active_directory]
type = "ldap"
hostname = "ms-ad.supercorp.com"
port = "389"
encryption = "none"
root_dn = "DC=supercorp,DC=com"
bind_dn = "CN=bind_user,OU=Users,DC=supercorp,DC=com"
bind_pw = "*******"

Danach muss der Import im Icinga Director erstellt werden. Dazu geht ihr im Icinga Director auf Automation => Import Source => Add und legt den Import wie folgt an:

Wichtig ist hierbei der LDAP Filter mit mail=*. Dadurch werden nur Benutzer importiert die auch eine E-Mail-Adresse haben. Bei Benutzern ohne E-Mail-Adresse würde der spätere Sync fehlschlagen.
Im Anschluss erstellt ihr den dazu passenden Sync unter Automation => Sync Rule => Add


Die Customvariable var.import wird zwar nicht zwingend benötigt, ich verwende sie aber um später die Möglichkeit zur Filterung zu haben. So kann man (neben der History Funktion) erkennen ob ein Kontakt manuell oder vom Import angelegt worden ist.

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.

Apache und viele, viele User

Kollege Lennart hat zwar schon dankenswerterweise einiges zu Apache, Openldap und Active Directory geschrieben trotzdem ist dieses Thema noch nicht völlig erschöpft. Ich möchte diesmal die Anleitung liefern wie man mehrere verschiedene LDAP-Server bei der Apache-Authentifizierung nutzt. Auch nutzbar ist diese Lösung um mehrere Einstiegspunkte in den gleichen Verzeichnisbaum zu bekommen.
Die einen fragen sich nun wo soll da bitte die Schwierigkeit sein, die anderen wozu sollte man so etwas brauchen. Die Schwierigkeit hierbei stellt der LDAP-Provider dar, der nur eine LdapAuthURL akzeptiert. Der Grund dafür mehrere zu brauchen können mehrere Verzeichnisdienste für verschiedene Anwendergruppen sein oder auch ein Struktur im Active Directory, bei der sonst neue Gruppen gebildet und gepflegt werden müssten oder ein Verschieben der Benutzer innerhalb des Baums aus organisatorischen oder gar technischen Gründen nicht möglich ist.
Die Lösung hierfür heißt mod_authn_alias (oder ab 2.4 mod_authn_core). Mit diesem Modul lässt sich ein Alias für einen Authentfizierungs-Provider erstellen, so dass es möglich wird diesen mehrfach zu verwenden. Die Konfiguration könnte dann folgendermaßen aussiehen:

<AuthnProviderAlias ldap admins>
   AuthLDAPBindDN "CN=serviceaccount,DC=netways,DC=de"
   AuthLDAPBindPassword strenggeheim
   AuthLDAPURL "ldap://server1.netways.de server2.netways.de/OU=admins,DC=netways,DC=de?samaccountname"
</AuthnProviderAlias>
<AuthnProviderAlias ldap entwickler>
   AuthLDAPBindDN "CN=serviceaccount,DC=netways,DC=de"
   AuthLDAPBindPassword strenggeheim
   AuthLDAPURL "ldap://server1.netways.de server2.netways.de/OU=entwickler,DC=netways,DC=de?samaccountname"
</AuthnProviderAlias> 

Diese Konfiguration muss einmalig und vor der Verwendung eingebunden werden. Daher bietet sich ein Dateiname wie 00provider.conf an mit dem die Konfiguration im Apache-Konfigurationsverzeichnis abgelegt wird.
Für die Verwendung bietet es sich dann eine Datei auth.inc anzulegen, die dann in den einzelnen Konfigurationsdateien für die Webanwendungen mit include eingebunden werden kann. Diese sieht dann beispielsweise so aus:

AuthName "Icinga Access"
AuthType Basic
AuthBasicProvider admins entwickler
Require valid-user

Wer zusätzlich noch einen Fallback für einen anderen Provider benötigt kann diesen einfach hinzufügen und je nach Apache-Version einen Blick auf AuthzLDAPAuthoritative (2.2) oder RequireAny (2.4) werfen.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Weekly Snap: Source Code Pro, Apace & Active Directory, JMX

weekly snap 11 – 15 February introduced new products at our shop and shared tips for programmers and sys admins alike.
Eva began by counting 65 days down to the OSDC with Jochen Lillich’s presentation on Kanban.
Lennart then solved an Apache and Active Directory configuration problem as Johannes trialled Adobe’s coding font, Source Code Pro.
Ronny followed with his quick guide to activating JMX and Christian announced the arrival of new power distribution units by Gude to our online hardware store.
Finally, Georg gave the adjudication reins over to our readers to decide which poet should win our competition for two TKS Supermicro 2HE servers.

Nochmal Apache und Active Directory

Letzte Woche hatte ich bei einem unserer Kunden bei der Apache-Konfiguration mit SSO und LDAP-Gruppen-Autorisierung ein Problem. Für meinen AD-Account funktionierte die Anmeldung. Für einen weiteren Account, mit der selben Gruppenzugehörigkeit, jedoch nicht. Die verwendete Apache-Konfiguration sah wie folgt aus:

AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbServiceName HTTP
KrbAuthRealms example.org
Krb5KeyTab /etc/apache2/apache2.keytab
Require valid-user
AuthzLDAPAuthoritative on
AuthLDAPURL "ldap://example.org/DC=example,DC=org?userPrincipalName?sub?"
AuthLDAPRemoteUserAttribute "userPrincipalName"
AuthLDAPBindDN "ldap@example.org"
AuthLDAPBindPassword XXX
Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=authorized_group,DC=example,DC=org

Das Problem war, dass das Kerberos-Realm nicht mit der Domäne im userPrincipalName übereinstimmte. Nach einem Update des Kerberos-Auth-Moduls auf Version 5.4, konnten wir mit der neuen Option KrbLocalUserMapping, das Realm abschneiden. Jetzt ließ sich bei der gruppenbezogenen Autorisierung via LDAP der sAMAccountName verwenden. Die funktionsfähige Konfiguration sieht dann abschließend so aus:

AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbServiceName HTTP
KrbAuthRealms example.org
KrbLocalUserMapping On
Krb5KeyTab /etc/apache2/apache2.keytab
Require valid-user
AuthzLDAPAuthoritative on
AuthLDAPURL "ldap://example.org/DC=example,DC=org?sAMAccountName?sub?"
AuthLDAPRemoteUserAttribute "sAMAccountName"
AuthLDAPBindDN "ldap@example.org"
AuthLDAPBindPassword XXX
Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=authorized_group,DC=example,DC=org

Zum Schluss möchte ich noch darauf hinweisen, dass die verwendete Option weder auf der Projektseite, noch im README des Source-Tarballs dokumentiert ist, sondern lediglich im ChangeLog vermerkt ist.
Weitere Artikel zu diesem Thema sind:
LDAP-Filter zur Autorisierung bei rekursiven Gruppen
SSO bei Apache mit gruppenbezogener Authentifizierung gegen ein Active Directory

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

LDAP-Filter zur Autorisierung bei rekursiven Gruppen

Bevor wie zum Eingemachten kommen zuerst ein paar klärende Worte zum Titel. Hier ist unter rekursiven Gruppen, eine rekursive Gruppenstruktur gemeint, bei der eine Gruppe eine weitere Gruppe als Mitglied enthalten kann. Der Filter

&(sAMAccountName=__USERNAME__)(member=CN=group,DC=netways,DC=de)

leistet dies leider nicht, so dass Mitglieder einer Gruppe, die Mitglied von CN=group ist, nicht authorisiert sind. Mit dem memberOf-Overlay, ist dies mit einer eingebauten “Funktion” jedoch leicht möglich:

&(sAMAccountName=__USERNAME__)(memberOf:1.2.840.113556.1.4.1941:=CN=group,DC=netways,DC=de)

Das Active Directory von Microsoft bringt das memberOf-Overlay von Hause aus mit. Bei Openldap kann es als Modul nachgeladen werden.

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: memberof
dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf

Eine zur Authentifizierung zusätzliche Autorisierung bei einem Apache-Webserver, wie in SSO bei Apache mit gruppenbezogener Authentifizierung gegen ein Active Directory beschrieben, sähe dann wie folgt aus:

AuthzLDAPAuthoritative on
AuthLDAPURL "ldap://dc.netways.de/dc=netways,dc=de?userPrincipalName"
AuthLDAPBindDN "cn=ads,cn=Users,dc=netways,dc=de"
AuthLDAPBindPassword ********
Require ldap-filter memberOf:1.2.840.113556.1.4.1941:=CN=group,DC=netways,DC=de
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

SSO bei Apache mit gruppenbezogener Authentifizierung gegen ein Active Directory

Heute soll sich dieser Blogeintrag also um Single Sign On im Apache- und Active Directory-Umfeld drehen. Ziel ist es, sich an einem Webserver per Kerberos-Ticket zu authentifizieren und nachgelagert zu prüfen, ob der Benutzer sich ebenfalls in der Gruppe befindet, dessen Mitglieder Zugriff auf die Wibsite erhalten dürfen.
Zuerst muss ein Benutzer im Active Directory angelegt werden. Danach erzeugen wir auf unserem Domain Controller einen Schlüssel und fügen diesem Benutzer eine PrincipalName hinzu. Also Verschlüsselung wählen wir RC4-HMAC, da dies von Windows XP unterstützt wird. Die ab Windows Server 2008 hinzugekommenden Verschlüsselingen auf AES basierend werden erst von Windows Vista und Windows 7 unterstützt.
ktpass -out apache2.keytab \
   -mapuser www@NETWAYS.DE \
   -princ HTTP/www.netways.de@NETWAYS.DE \
   -pass login123 \
   -ptype KRB5_NT_PRINCIPAL \
   -crypto RC4-HMAC-NT \
In unserem Beispiel haben wir den Benutzer www angelegt. Unsere NS-Domäne lauetet netways.de und unser Kerberos-Realm NETWAYS.DE. Mit dem Kommando ktpass weisen wir nun diesem Benutzer über die Option -mapusr und -princ den PrincipalName HTTP/www.netways.de@NETWAYS.DE zu. Der Schlüssel erhält das Passwort login123 mit +rndpass kann man diesen auch zufällig erzeugen lassen. Erzeugt man den Schlüssel jedoch zufällig, ist es dann aber leider nicht möglich den Schlüssel auf dem Linux-Serverauf Korrektheit zu überprüfen.
Nachdem wir nun den Schlüssel erzeugt haben, kopieren wir die Datei apache2.keytab auf sicherem Wege auf unseren Webserver.
Die Kerberos-Client-Konfiguration /etc/krb5.keytab auf unserem Linux-Server sieht wie folgt aus:
[libdefaults]
     default_realm = NETWAYS.DE
[realms]
     NETWAYS.DE = {
          kdc = dc.netways.de
          default_domain = netways.de
          ktpasswd_server = dc.netways.de
     }
[domain_realm]
     .netways.de = NETWAYS.DE
Unsere apache2.keytab können wir nun mit kinit auf Korrektheit prüfen.
kinit -t /etc/apache2/apache2.keytab HTTP/www.netways.de
Der PrincipalName kann im Vorfeld auch schon mit klist ermittelt werden.
klist -t -k /etc/apache2/apache2.keytab
Für den Apache Webserver werden noch drei zusätzliche Module benötigt. Die Module mod_ldap und mod_authnz_ldap, im Gegensatz zu mod_auth_kerb sind diese beiden Module Bestandteil vom Apache-Paket. Das Module mod_auth_kerb muss nötigenfalls selbst übersetzt werden.
a2enmod auth_kerb
a2enmod ldap
a2enmod authnz_ldap
Für unser Beispiel  benötigen wir noch einen Active Directory Benutzer ads, um auf den LDAP-Server des DC zugreifen zu können. Außerdem die Gruppe ApacheAcces, deren Mitglieder auf unsere Website zu greifen dürfen.
AuthType Kerberos
AuthName "Kerberos Login"
KrbAuthRealm NETWAYS.DE
KrbServiceName HTTP
Krb5Keytab /etc/apache2/apache.keytab
KrbMethodK5Passwd on
KrbMethodNegotiate on
AuthzLDAPAuthoritative on
AuthLDAPURL "ldap://dc.netways.de/dc=netways,dc=de?userPrincipalName"
AuthLDAPBindDN "cn=ads,cn=Users,dc=netways,dc=de"
AuthLDAPBindPassword ********
Require ldap-group cn=ApacheAccess,cn=Users,dc=netways,dc=de
Zu Abschuss nicht vergessen den Browser für den SSO-Zugriff zu konfigurieren. Beim Firefox geschieht dies durch den Aufruf der URL about:config.
network.negotiate-auth.trusted-uris     .netways.de

Weitere Artikel zum Thema:
LDAP-Filter zur Autorisierung bei rekursiven Gruppen
Nochmal Apache und Active Directory

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.