124 IPA, das steht für Identity, Policy und Audit

FreeIPA
IPA, das steht für Identity, Policy und Audit.
Doch das Open-Source-Identity-ManagementSystem FreeIPA, das diese Abkürzung im Namen
führt, soll später sogar noch mehr können: Es
wird dann auch Zertifikate, Policy- und AuditEinstellungen an zentraler Stelle konfigurieren
und verwalten und mit Hilfe von Plugins Microsofts Active-Directory anbinden. Thorsten Scherf
124
Linux Technical Review, Ausgabe 10
System
Die Idee des noch recht jungen Projekts FreeIPA
[1] war, eine Vielzahl bekannter Open-SourceProjekte unter einem Hut zu bringen und die
verschiedenen Kommandozeilen-Tools und
Webfrontends in einem System zu vereinen. Das
Resultat sollte besonders leicht bedienbar sein
und den Administrator nicht mir Konfigurationsorgien überfordern.
Für jede Teilaufgabe, der sich FreeIPA stellen
will, gibt es bereits mindestens eine eingeführte
Lösung: Ein LDAP-Server eignet sich für die Benutzerverwaltung, zum sicheren Management
von Passwörter existiert seit langer Zeit das
Kerberos-Protokoll, der Audit-Daemon kann
sämtliche Benutzer- und Prozessaktivitäten
nachverfolgen und schließlich lässt sich mit
SELinux eine fein granulierte Sicherheitspolicy
auf Grundlage der Mandatory-Access-Control
einrichten. Der Nachteil aller dieser Einzellösungen besteht allerdings darin, dass sie nicht
ohne Weiteres in eine zentrale Verwaltung integrierbar sind.
So ist es beispielsweise nicht möglich, die Audit-Logs von mehreren Maschinen zentral zu
verwalten. Auch das Verteilen einmal erzeugter
SELinux Policy-Module auf mehrere Maschinen ist ohne selbstgebaute Skripte bisher nicht
möglich. Zwar existiert eine Vielzahl von proprietären Lösungen, die jedoch meist recht teuer
und unflexibel sind. Erschwerend kommt hinzu,
dass die Komponenten nicht immer reibungslos
zusammenarbeiten mögen.
Eine weitere Alternative besteht im Einsatz von
Microsofts Active-Directory Server (ADS) als
erprobter Directory-Lösung auf LDAP/​Kerberos-Basis. Für das Andocken von Linux-Umgebungen an das ADS gibt es bereits das ebenfalls
erprobte Samba oder beispielsweise Likewise
[2]. Ein großer Nachteil besteht jedoch darin, dass im ADS keinerlei Policy- oder Audit-
Management für Linux-Systeme extistiert.
Hierfür müsste man dann wieder auf andere
Programme zurückgreifen, was den ProduktDschungel erneut vergrößert, und genau dies
möchte man ja vermeiden. Zusätzlich ließe
sich natürlich auch noch darüber diskutieren,
ob man sicherheitsrelevante Daten wirklich in
die Hand eines Anbieters geben möchte, dessen
Software für ihre Anwender undurchschaubar
und verschlossen bleibt.
Wer das verneint oder die sonstigen Nachteile
des Active Directory höher als dessen Nutzen
bewertet, dem bietet sich FreeIPA als ein noch
recht junges, durch Red Hat gesponsortes Projekt an, das die Open-Source-Community intensiv weiterentwickelt.
Red Hat supported mit Enterprise IPA eine kommerzielle Variante [3]. In der aktuellen Version
liegt der Focus auf dem Identity-Management.
In Version 2.0, die für Anfang nächsten Jahres erwartet wird, folgen dann die Policy- und
Audit-Komponenten. Das modulare Konzept
ermöglicht es, sukzessive die verschiedensten
Bausteine zum Core-System hinzuzufügen. So
wird sich in Zukunft beispielsweise das DogtagZertifikatsystem [5] um die Verwaltung von
X.509-Zertifikaten kümmern, FreeRadius um
RAS-Benutzer und ‑Geräte und der bekannte
Audit-Daemon soll die zentrale Speicherung
von Audit-Informationen übernehmen. Das Zusammenspiel der einzelnen Komponenten der
FreeIPA-Version 1 ist in Abbildung 1 dargestellt.
Server Installation
Bevor es an die Installation des eigentlichen FreeIPA-Servers geht, ist sicherzustellen, dass sich
die Namen aller verwendeten Maschinen via
DNS auflösen lassen. Erweitert man den vorhanden DNS-Server um einige Service-Einträge
(SRV-Records), erleichtert das später auch die
Abbildung 1: Bekannte Open-Source-Tools laufen bei FreeIPA
unter einer Haube.
Abbildung 2: Client-Zugriff auf die einzelnen Komponenten
des IPA-Servers.
Linux Technical Review, Ausgabe 10
125
System
Konfiguration der Client-Maschinen, weil sie
dann über eine DNS-Abfrage Informationen
über ihre zuständigen Server und die KerberosRealm erhalten. Eine manuelle Konfiguration ist
so kaum mehr nötig.
Bei der Installation des FreeIPA-Servers legt
dieser auf Wunsch eine beispielhafte DNSZonendatei mit allen notwendigen Einträgen an.
Mit Hilfe dieser Datei lässt sich dann der eigene
DNS-Server erweitern (Listing 1).
Möchte man den FreeIPA-Server auf einem
Fedora-System installieren, so gelingt dies durch
den Aufruf von »yum ‑y install ipa‑server«.
Der Server sowie alle weiteren Pakete sind seit
Fedora 8 in den Standard-Repositories enthalten. Die eigentliche Konfiguration geschieht im
Anschluss durch das Tool »ipa‑server‑install«.
Wer direkt eine passende DNS-Zonendatei erzeugen möchte, ruft das Tool mit der Option
»‑‑setup‑bind« auf. Die Zonendatei befindet
sich im Anschluss im Tmp-Ordner.
Durch den Aufruf der Setup-Routine werden nun die folgenden Komponenten auf der
Maschine installiert:
n NTP
n Fedora Directory Server
n MIT Kerberos
n Apache/​TurboGears
n SELinux targeted Policy für FreeIPA
Das Installationsprogramm fragt jetzt die notwendigen Informationen wie LDAP Base DN,
Kerberos Realm, Servername und so weiter ab
und schon nach wenigen Minuten ist der Server
inklusive aller Komponenten einsatzbereit. Mit-
02 @ IN SOA devel‑srv1.virt.foo.de.
IN TXT
0 100 389 devel‑srv1.virt.foo.de.
126
IN SRV 0 100 123
krbtgt/[email protected]
[root@devel‑srv1 ~]#
Möchte man einen neuen Benutzer zum Directory/​Kerberos-Server hinzufügen, so reicht folgender Aufruf:
Listing 2: Informationen ab­
fragen
01 [root@devel‑srv1 ~]# ldapsearch ‑Y
GSSAPI uid=tscherf ‑LLL
02 SASL/GSSAPI authentication started
03 SASL username: [email protected]
04 SASL SSF: 56
05 SASL installing layers
06 dn: uid=tscherf,cn=users,cn=accounts,
dc=virt,dc=foo,dc=de
07 uid: tscherf
08 objectClass: top
11 objectClass: inetOrgPerson
12 objectClass: inetUser
19 sn: Scherf
20 homeDirectory: /home/tscherf
22 givenName: Thorsten
devel‑srv1.virt.foo.
13 ;ntp server
14 _ntp._udp
09/19/08 13:50:51 09/20/08 13:50:48 U
21 krbPrincipalName: [email protected]
VIRT.FOO.DE
IN SRV 0 100 88
Expires U
Service principal
18 gecos: tscherf
11 ; kerberos servers
12 _kerberos._tcp
Valid starting
17 gidNumber: 1002
192.168.122.100
09 ;kerberos realm
10 _kerberos
Default principal: [email protected]
16 loginShell: /bin/sh
07 ; ldap servers
IN SRV
Ticket cache: FILE:/tmp/krb5cc_0
15 objectClass: radiusprofile
devel‑srv1.virt.foo.de.
05 ; Internet address resource records( A )
08 _ldap._tcp
[root@devel‑srv1 ~]# klist ‑5
14 objectClass: krbPrincipalAux
03 ; Name server resource records ( NS )
IN A
[root@devel‑srv1 ~]#
13 objectClass: posixAccount
( 2003040100 ;serial number ... )
06 devel‑srv1
Password for [email protected]:
10 objectClass: organizationalPerson
01 ; Ausschnitt aus einer beispielhaften DNS‑Zonendatei
IN NS
[root@devel‑srv1 ~]# kinit admin
09 objectClass: person
Listing 1: DNS erweitern
04 @
tels »kinit admin« lässt sich die korrekte Funktionsweise des Kerberos-Servers verifizieren,
indem man ihn nach einem Benutzer-Ticket für
»admin« fragt:
devel‑srv1.virt.foo.
23 cn: Thorsten Scherf
24 uidNumber: 1100
25 memberOf: cn=ipausers,cn=groups,cn=ac
counts,dc=virt,dc=foo,dc=de
Linux Technical Review, Ausgabe 10
System
[root@devel‑srv1 ~]# ipa‑adduser U
‑f Thorsten ‑l Scherf tscherf
Password:
Password (again):
tscherf successfully added
Hat man sich bei der Eingabe des Passwortes an
die Passwort-Komplexitäts-Policy gehalten, so
bestätigt der Aufruf von »ipa-finduser«, dass der
Benutzer nun auf dem Directory-Server vorhanden ist:
[root@devel‑srv1 ~]# ipa-finduser tscherf
Full Name: Thorsten
Scherf Home Directory: /home/​
tscherf
Login Shell: /bin/​
sh Login: tscherf
Wer mehr Informationen zu den verwendenten
LDAP-Attributen benötigt, kann natürlich auch
schon eine mit Kerberos authentifizierte Verbindung zum LDAP-Server aufbauen und alle relevanten Informationen abfragen (Listing 2).
Das Tool »klist« zeigt nun auch das übertragene
Service-Ticket für den LDAP-Server an:
[root@devel‑srv1 ~]# klist ‑5
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires U
Service principal
09/19/08 13:57:28 09/20/08 13:57:26 U
krbtgt/[email protected]
09/19/08 13:57:42 09/20/08 13:57:26 U
ldap/devel‑[email protected]
Natürlich lassen sich die Aufgaben auch bequem über ein Webinterface erledigen. Hierfür
ist allerdings im Vorfeld der Webbrowser entsprechend zu konfigurieren. Beim Firefox lassen
sich die aktuellen Konfigurationseinstellungen
über »about:config« anzeigen. Die folgenden
Anweisungen sind individuell anzupassen:
Abbildung 3: Die Startseite des IPA Webinterfaces.
lungen zulässt. Wem beispielsweise die Komplexitäts-Policy für Benutzer-Passwörter zu streng ist,
der kann sie den eigenen Bedürfnissen anpassen.
Client-Konfiguration
Ein FreeIPA-Client existiert nicht nur für
Fedora und Red Hat Enterprise Linux (RHEL),
sondern daneben gibt es Clients für eine Vielzahl verschiedener Unix-Varianten wie beispielsweise Solaris, AIX, HP-UX oder auch
Mac OS X. Auf einem Fedora-System gelingt
die Installation wieder ganz einfach, nämlich nur mit einem schlichten Yum-Aufruf:
»yum install ipa‑client ipa‑admintools«.
Wenn man nun die »/etc/krb5.conf«-KerberosKonfigurationsdatei des Servers auf den Client
überträgt, ist lediglich noch der Aufruf von
»ipa‑client‑install« notwendig, damit die Installation des Clients startet. Dank des Eintrages
»dns_lookup_realm = true« in der »/etc/krb5.
conf« fragt der Client nun brav seinen DNSServer nach allen notwendigen Konfigurationsinformationen (Listing 3).
network.negotiate‑auth.trusted‑uris U
.virt.foo.de
network.negotiate‑auth.delegation‑uris U
.virt.foo.de
network.negotiate‑auth.using‑native‑U
gsslib true
Nachdem eine HTTPS-Verbindung zum FreeIPA-Server aufgebaut ist, lassen sich sehr komfortabel Benutzer über das Webinterface einrichten oder abfragen. Abbildung 3 zeigt, dass
das die Web-GUI natürlich auch andere Einstel-
Abbildung 4: Über das Webinterface lassen sich Benutzer sehr bequem
zum Directory hinzufügen.
Linux Technical Review, Ausgabe 10
127
System
Kerberos-Services
Nun geht es an die Konfiguration des ersten eigenen Kerberos-Service. Als Beispiel dient ein
NFS-Server, der sich von den Client-Maschinen
über das sichere NFSv4-Protokoll mit KerberosAuthentifizierung ansprechen lässt. Zusätzlich
soll der Server auch für Datenintegrität und
Vertraulichkeit sorgen. Hierfür richten wir auf
dem IPA-Server eine NFS-Freigabe ein:
nfs/​
devel-srv1.virt.foo.de
[root@devel-srv1 ~]# ipa-getkeytab U
nfs/​
devel-srv1.virt.foo.de ‑k U
/data
gss/krb5(rw,fsid=0,subtree_check)
/etc/​
krb5.keytab
/data
gss/krb5p(rw,fsid=0,subtree_check)
Keytab successfully retrieved and U
/data
gss/krb5i(rw,fsid=0,subtree_check)
stored in: /etc/​
krb5.keytab
Listing 3: Additive Vererbung
01 [root@devel‑client ~]# ipa‑client‑install
02 Discovery was successful!
03 Realm: VIRT.FOO.DE
04 DNS Domain: virt.foo.de
05 IPA Server: devel‑srv1.virt.foo.de
06 BaseDN: dc=virt,dc=foo,dc=de
07 08 Continue to configure the system with these values? [y/N]:
y
09 10 Created /etc/ipa/ipa.conf
Die Client-Konfiguration verläuft ähnlich. Auch
hier ist ein NFS-Service-Principal zu erzeugen
und lokal in der »/etc/krb5.keytab«-Datei zu
speichern. Ob dies geklappt hat, lässt sich leicht
über das Tool »ipa‑findservice« herausfinden. Es
sollte auf Wunsch alle vorhandenen Host- und
Service-Principals aus der Keytab-Datei auf­listen.
Damit die notwendigen NFS-Client Dienste
»rpcgssd« und »rpcidmapd« korrekt starten, ist
auch hier ein Eintrag »SECURE_NFS=yes« in
der Datei »etc/sysconfig/nfs« vorzunehmen.
Nun sollte einem erfolgreichen NFSv4-Mount
mit der höchstmöglichen Sicherheitsstufe nichts
mehr im Wege stehen:
[root@devel‑client ~]# mount ‑v ‑t nfs4 U
11 Configured /etc/ldap.conf
‑o sec=krb5p devel‑srv1:/ /mnt/nfs4
12 LDAP enabled
mount: pinging: prog 100003 vers 4 prot U
13 nss_ldap is not able to use DNS discovery!
14 Changing configuration to use hardcoded server name:
devel‑srv1.virt.foo.de
tcp port 2049
[root@devel‑client ~]#
[root@devel‑client ~]# df ‑T /mnt/nfs4
15 Kerberos 5 enabled
Filesystem
16 NTP enabled
Type
1K‑blocks
Used U
Available Use% Mounted on
17 Client configuration complete.
devel‑srv1:/
18 19 Über „kinit admin“ auf dem Client lässt sich die Verbindung
zum Server
20 testen. Hat dies funktioniert wollen wir für den Client
direkt ein
21 Host‑Principal in der Kerberos‑Datenbank erzeugen und das
Passwort hierfür
nfs4
6792608
5071360 U
1370656 79% /mnt/nfs4
Ein Blick in die Logdatei des Kerberos-Servers
bestätigt die Übertragung eines NFS-ServiceTickets an den Client:
[root@devel‑srv1 ~]# tail ‑n1 /var/log/U
krb5kdc.log
22 lokal auf dem Client speichern:
Sep 19 15:00:36 devel‑srv1.virt.foo.de U
23 24 [root@devel‑client ~]# ipa‑addservice host/devel‑client.
virt.foo.de
25 [root@devel‑client ~]# ipa‑getkeytab host/devel‑client.
virt.foo.de ‑k /etc/krb5.keytab
krb5kdc[8266](info): TGS_REQ (7
etypes {18 17 16 23 1 3 2})
192.168.122.126:U
ISSUE: authtime 1221828762,
etypes {rep=18 tkt=1 ses=1}, nfs/devel‑U
26 Keytab successfully retrieved and stored in: /etc/krb5.
128
[root@devel-srv1 ~]# ipa-addservice U
[root@devel‑srv1 ~]# cat /etc/exports
Ein »echo SECURE_NFS=yes > /etc/sysconfig/
keytab
nfs« sorgt dafür, s nach einem »service nfs start«
alle notwendigen NFS-Dienste verfügbar sind.
In der Kerberos-Datenbank ist nun noch ein
Service-Principal für den NFS-Dienst zu erzeugen und die Keytab-Datei des Servers zu exportieren:
[email protected] for U
nfs/devel‑[email protected]
Linux Technical Review, Ausgabe 10
System
Angemerkt sei noch, dass FreeIPA die komplette
Kerberos-Konfiguration im LDAP speichert
(Abbildung 5). Da die nativen Kerberos-Tools
wie »kadmin« oder »kadmin.local« keine native
LDAP-Schnittstelle bieten, darf man sie zum
Verwalten der Kerberos-Datenbank keinesfalls
einsetzen. Für sämtliche Administrationsarbeiten muss der Admin stattdessen immer die
FreeIPA-Tools benutzen.
Hochverfügbare Daten
Nachdem nun eine grundlegende Konfiguration
des Servers fertig gestellt ist, sollte man die Daten
des Directory-Servers auf eine zweite Maschine
replizieren. Da FreeIPA auch die komplette Kerberos-Konfiguration und -Datenbank im LDAP
vorhält, hat man somit im Handumdrehen einen
zweiten Master-Server aufgesetzt. Dieser ist nun
ebenfalls in der Lage, Änderungen von Clients
entgegenzunehmen und diese auf den jeweils
anderen Server zu replizieren.
Nach Ausfall eines Masters wären die Daten so
trotzdem noch über den anderen Master verfügbar und ließen sich dort sogar ändern. Ist
der ausgefallene Server wieder online, werden
die geänderten Daten auf ihn zurückrepliziert.
Auch zur Lastverteilung bietet sich der Einsatz
mindestens zweier Server an. Speichert man die
Daten an mehreren, geografisch voneinander
getrennten Standorten, so sollte man sich überlegen, unter Umständen noch weitere Server
zu konfigurieren und als Replicas einzurichten,
damit nicht für jede Abfrage oder Änderung am
Directory eine WAN-Verbindung nötig ist.
Die Konfiguration geht auch hier sehr schnell
von der Hand. Auf dem ersten Master ist eine
Konfigurationsdatei mit allen notwendigen Information für den anderen Server zu erzeugen:
Nun kopiert man einfach die so erzeugte Datei
auf den Replica-Host und startet dort die Installation:
[root@devel‑srv1 ~]# scp /var/lib/ipaU
/replica‑info‑devel‑srv2.virt.foo.de U
root@devel‑srv2:/tmp/
[root@devel‑srv1 ~]# ipa‑replica‑install
/tmp/replica‑info‑devel‑srv2.virt.foo.de
Ist das Installationsprogramm ohne Fehler
durchgelaufen, startet im Anschluss eine Replikation der LDAP-Datenbank. Fügt man
diese Replica nun noch seiner DNS-Zonendatei
hinzu, stehen zwei unterschiedliche Server bereit. Die so eingerichteten Replizierungsvereinbarungen (replication agreements) lassen sich
mittels »ipa‑replica‑manage« anzeigen oder
auch nachträglich ändern:
[root@devel‑srv1 ~]# ipa‑replica‑manageU
list
Directory Manager password:
devel‑srv2.virt.foo.de
Active-Directory-Sync
Mir Hilfe von »ipa‑replica‑manage« wird es in
der FreeIPA Version 1.2 auch möglich sein, Daten zwischen einem Windows Active-Directory-
[root@devel‑srv1 ~]# ipa‑replica‑prepareU
devel‑srv2.virt.foo.de
Determining current realm name
Getting domain name from LDAP
Preparing replica for devel‑srv2.virt.U
foo.de from devel‑srv1.virt.foo.de
Creating SSL certificate for the U
Directory Server
Creating SSL certificate for U
the Web Server
Copying additional files
Finalizing configuration
Packaging the replica into replica‑info‑U
devel‑srv2.virt.foo.de
Abbildung 5: FreeIPA speichert die KerberosDatenbank in einem LDAP-Container.
Linux Technical Review, Ausgabe 10
129
System
Server und einem FreeIPA-Server zu synchronisieren. In der aktuellen Entwickler-Version
von FreeIPA ist dieses Feature bereits enthalten.
Hierfür braucht man auf dem Windows-Rechner ein TLS/​SSL-Zertifikat, das für eine Replizierung der Daten vom AD-Server nach FreeIPA
zwingend notwendig ist. Eine Anleitung hierfür
befindet sich im Fedora Wiki [4].
Das verwendete CA-Zertifikat ist nun zur Verifizierung des TLS/​SSL-Zertifikats des AD-Servers
auf den FreeIPA-Server zu kopieren. Ruft man
dort das Installationsprogramm »ipa‑server‑install« auf, so wird das Windows-Sync-Plugin
automatisch mitinstalliert. Zum Einsatz kommt
es aber nur dann, wenn man später mittels
»ipa‑replica‑manage« eine Daten-Replizierung
zwischen einem Windows- und einem FreeIPAServer einrichtet. Das Tool kennt hierfür einige
neue Optionen
n --winsync definiert eine Daten-Replizierung
zwischen einem Windows- und FreeIPA
n --binddn bestimmt den Benutzer für die Anmeldung am Active-Directory
n --bindpw Passwort für diesen Benutzer
n --cacert Pfad zum ASCII/​PEM codierten CAZertifikat, welches zum Signieren des TLS/​
SSL-Zertifikats des Windows-Servers verwendet wurde. Dieses wird anschließend im
FreeIPA-Zertifikatspeicher vorgehalten
Hat man alle notwendigen Informationen
angegeben, werden alle Daten, die sich im
Container des Active-Directory-Benutzers
befinden, auf den FreeIPA-Server synchronisiert. Auf sie können dann alle Unix/​LinuxIPA-Clients über eine native Schnittstelle zugreifen. Wichtig dabei ist, dass neue Benutzer,
die sowohl auf Windows- wie auch auf LinuxClients zur Verfügung stehen sollen, im ADS
anzulegen sind, weil die Synchronisierung nur
in eine Richtung verläuft.
Ausblick
Wie dieser Artikel zeigt, liegt der Fokus der aktuellen FreeIPA-Version 1 auf der Verwaltung
von User- und Gruppen-Identitäten. Bestehende NIS-Lösungen lassen sich mit FreeIPA
einfach in eine sichere LDAP-Umgebung mit
Kerberos-Passwörtern migrieren. Auch die Synchronisierung mit einem bestehenden ActiveDirectory-Server ist in der Entwicklerversion
bereits möglich und sollte bei Erscheinen dieses
Artikels auch in der offiziellen FreeIPA-Version
verfügbar sein.
130
In der Version 2 Anfang nächsten Jahres kommen weitere Features hinzu. Das bestehende
Identitätsmanagement wird so erweitert, dass
sich nicht nur Benutzer- und Gruppen-Konten,
sondern auch Maschinen-Konten verwalten lassen. Das ist teils jetzt schon möglich, allerdings
nur manuell. Später passiert das automatisch bei
der Client-Installation.
Als weiteres Feature wird eine CertificateAuthority (CA) zur Ausgabe von Zertifikaten
für Benutzer und Dienste zur Verfügung stehen.
Natürlich werden auch die beiden fehlenden
IPA-Komponenten Policy (P) und Audit (A)
zum Leben erweckt. Zur Policy-Komponente
wird nicht nur das Verwalten von SELinuxRegelsätzen zählen. Auf dem Plan der Entwickler steht ebenfalls die zentrale Verwaltung von
PAM-Einstellungen.
Die Audit-Komponente wird primär auf Funktionen des bekannten Audit-Daemons zurückgreifen, um die Einhaltung einer bestehenden
IP-Compliance sicherzustellen. Zum zentralen
Ausrollen von entsprechenden Audit-Regeln
kommt dann natürlich auch das Einsammlen
der entsprechenden Audit-Events der einzelnen
Maschinen hinzu. Sie lassen sich dann auf dem
FreeIPA-Server für weitere Reporting Funktionen speichern und auswerten.
Fazit
Mit IPA steht ein sehr leistungsfähiges Produkt
zur zentralen Speicherung von sicherheitsrelevanten Informationen zur Verfügung. Auch
wenn in der Version 1 der Fokus noch ganz
klar auf der Speicherung von Identitäten liegt
und Komponenten wie Zertifikats-, Audit- und
Policy-Verwaltung noch fehlen, so lässt sich
bereits jetzt erkennen, wo es hingehen soll. IPA
vereint und kombiniert eine Vielzahl bekannter
Produkte unter einem Hut und erleichtert deren
Installation und Konfiguration. (jcb)
nnn
Infos
[1]FreeIPA: [http://​­www.​­freeipa.​­org]
[2]Likewise: [http://​­www.​­likewisesoftware.​­com]
[3]Red Hat Enterprise IPA:
[https://​­www.​­redhat.​­com/​­promo/​­ipa/]
[4]WindowsSync-Howto:[http://​­directory.​
­fedoraproject.​­org/​­wiki/​­Howto:WindowsSync]
[5]Dogtag Zertifikatssystem:
[http://​­pki.​­fedoraproject.​­org/​­wiki/​­PKI_Main_
Page]
Linux Technical Review, Ausgabe 10