FreeIPA

Siehe auch

FreeIPA (Free Identity Policy Audit) ist eine web- und kommandozeilenbasierte Security Information Management-Lösung für Linux / UNIX-Netzwerkumgebungen. Es kombiniert bekannte Open Source-Komponenten und Standardprotokolle wie Linux (Fedora), 389 Directory Server, MIT Kerberos, NTP, DNS und Dogtag (Zertifikatssystem).

Ein FreeIPA-Server bietet zentralisierte Authentifizierungs-, Autorisierungs- und Kontoinformationen. In einer FreeIPA-Domäne können problemlos mehrere FreeIPA-Server parallel betrieben werden, um Redundanz und Skalierbarkeit zu gewährleisten.

Der 389 Directory Server speichert Daten zu Benutzern, Gruppen, Hosts und anderen Objekten und bietet eine vollständige Multi-Master-LDAPv3-Verzeichnisinfrastruktur. Die Single-Sign-On-Authentifizierung erfolgt über das MIT Kerberos KDC. Die Authentifizierungsfunktionen werden durch eine integrierte Zertifizierungsstelle erweitert, die auf dem Dogtag-Projekt basiert. Optional können Domänennamen über den integrierten ISC-Bindungsserver verwaltet werden.

Zugriffskontrolle, die Delegierung von Verwaltungsaufgaben etc. können vollständig zentralisiert und über die Web-Benutzeroberfläche oder das ipa-Befehlszeilentool verwaltet werden.

Das kommerzielle Produkt heisst „Red Hat IdM“.

Begriffe:

  • NGP: Netgroups Private

  • UPG: User Private Groups

Bemerkung

It is not possible to create new OU (Organizational Unit) in IPA at the moment. Instead, it is recommended to use IPA groups to create organizational groups. WebUI and CLI tool will not behave properly if the default DIT(Directory Information Tree) structure in IPA is changed.

Installation auf RHEL 7

/etc/hosts
# the fully-qualified name must come first
192.102.0.26 idm.ipa.test idm

Entweder als Bundle aus FreeIPA und DNS (FreeIPA speichert DNS-Records in seinem 389DS LDAP-Server):

yum -y install ipa-server-dns

… oder ohne, falls DNS-Server vorhanden sind, die die Zone bereits verwalten:

yum -y install ipa-server

Auf einem RHEL 7 Minimal werden damit knapp 300 Pakete installiert, unter anderem eine CA, NTPd, 389DS, Key Distribution Center (KDC) und Apache. Ein installiertes chronyd wird zugunsten von ntpd deaktiviert.

Setup starten:

ipa-server-install
# if IPA should do DNS
# ipa-server-install --setup-dns

Wichtig: es muss ein Zwei-Level Domainname sein, ein „.local“ o.ä. genügt nicht. Wird das gewählt, kann man keine Benutzer anlegen, da sich FreeIPA über ungültige E-Mail-Adressen beschwert (username@local ist keine gültige Mail-Adresse).

The IPA Master Server will be configured with:
Hostname:       idm.ipa.test
IP address(es): 192.102.0.26
Domain name:    ipa.test
Realm name:     IPA.TEST

Das Log-File zur Installation findet sich in /var/log/ipaserver-install.log.

Next steps:
    1. You must make sure these network ports are open:
        TCP Ports:
          * 80, 443: HTTP/HTTPS
          * 389, 636: LDAP/LDAPS
          * 88, 464: kerberos
        UDP Ports:
          * 88, 464: kerberos
          * 123: ntp

    2. You can now obtain a kerberos ticket using the command: 'kinit admin'
       This ticket will allow you to use the IPA tools (e.g., ipa user-add)
       and the web user interface.

Be sure to back up the CA certificates stored in /root/cacert.p12
These files are required to create replicas. The password for these
files is the Directory Manager password

Auf einem bestehenden Name-Server „autodiscovery“ einrichten:

/var/named/ipa.test.zone
_ldap._tcp IN SRV 10 10 389 idm.ipa.test.

Prüfen, ob vorhanden:

dig SRV _ldap._tcp.ipa.test

Das Anlegen von Home-Verzeichnissen auf Clients erlauben:

authconfig --enablemkhomedir --update
reboot

Auf dem FreeIPA Test: kinit -V admin (-V = verbose)

Installation im Docker-Container

Im Beispiel mit Podman auf Fedora 37:

sudo mkdir /var/lib/ipa-data
# https://hub.docker.com/r/freeipa/freeipa-server/tags
sudo podman run --name freeipa-server -ti -h ipa.example.test --read-only -v /var/lib/ipa-data:/data:Z freeipa/freeipa-server:fedora-37-4.10.1

Password-Expiration ändern

Im Standard laufen Passwörter nach 90 Tagen ab. Um das zu ändern, muss man die Password-Policy anpassen. Im FreeIPA Web-GUI:

  • Policy > Password Policies > global_policy > Max lifetime (days): 10000 (maximal sind 20000 Tage erlaubt)

  • IPA Server > Configuration > Default shell: /bin/bash

  • IPA Server > Configuration > Password Expiration Notification (days): 10

Durch Benutzer anpassbare Felder

Welche Felder dürfen User selbst administrieren? Es ist sinnvoll, folgende Felder hinzuzufügen:

  • IPA Server > Role-Based Access Control > Self Service Permissions > User Self service

    • mail

Rebuild Host/User Membership

  • Identity > Users or Hosts > Actions > Rebuild auto membership.

Read-Only LDAP User anlegen (Service-Account)

Wer für eine Applikation einen Read-only Benutzer benötigt (z.B. um in Nextcloud eine LDAP-Anbindung zu konfigurieren), erstellt diesen so:

ldapmodify_new_pw=$(< /dev/urandom tr -dc A-Za-z0-9 | head -c60)
echo $ldapmodify_new_pw

cat > /tmp/ldapmodify << EOF
dn: uid=freeipa-reader,cn=sysaccounts,cn=etc,dc=linuxfabrik,dc=it
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: freeipa-reader
userPassword: $ldapmodify_new_pw
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0
EOF

ldapmodify -H ldap://freeipa.example.com:389 -x -D 'cn=Directory Manager' -W -f /tmp/ldapmodify
# adding new entry "uid=freipa-reader,cn=sysaccounts,cn=etc,dc=linuxfabrik,dc=it"

\rm /tmp/ldapmodify

OpenSSH

Damit eine Anmeldung an den ssh-Daemon über FreeIPA möglich ist, ergänzt der FreeIPA-Agent dessen Konfiguration:

/etc/sshd/sshd_config
  # needed for FreeIPA
  AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
  AuthorizedKeysCommandUser nobody

LDAP-Anbindung einer Applikation

Im Beispiel: Nextcloud

  • Server-Account könnte unter uid=freeipa-reader,cn=sysaccounts,cn=etc,dc=example,dc=com aufzufinden sein.

  • User-Query: (&(|(objectclass=inetorgperson))(|(memberof=cn=nextcloud,cn=groups,cn=accounts,dc=example,dc=com)))

  • Login-Attribute: (&(objectclass=inetorgperson)(|(mail=%uid)(uid=%uid)))

CLI

Tool: ipa

kinit admin

ipa group-add
ipa group-add-member
ipa group-remove-member
ipa group-show
ipa hbacrule-find
ipa user-add
ipa user-find  # list all users
ipa user-mod
ipa user-mod firstname.last --gidnumber 1234567  # change primary group (GID)
ipa user-show --all admin

Ohne Interaktion: ipa --no-prompt

Delegation

Wie legt man einen Subadmin an, der nur Benutzer einer bestimmten, vom Admin angelegten Gruppe verwalten kann, beispielsweise „sales“? Um wie kommt man auf die Lösung hier?

Die zweite Frage ist einfach zu beantworten: Einen neuen Subadmin anlegen, und diesem die Role „User Administrator“ zuweisen. So sieht man, welche Permissions und Privilegien diese Art von Benutzer benötigt.

Beim Anlegen neuer Rollen, Privilegien und Permissions empfiehlt es sich, Prefixe in der Namensgebung zu verwenden, beispielsweise

  • bei Rollen: „<Kundenummer> Role <Rollenname>“, „My Role: <Rollenname>“, o.ä.

  • bei Privilegien: „<Kundenummer> Priv <Privilegienname>“, „My Priv: <Privilegienname>“, o.ä.

  • bei Permissions: „<Kundenummer> Perm <Permissionname>“, „My Perm: <Permissionname>“, o.ä.

Die Berechtigungen werden in der Reihenfolge angelegt:

  1. IPA Sever > Role-Based Access Control > Permissions

  2. IPA Sever > Role-Based Access Control > Privileges (fasst Permissions zusammen)

  3. IPA Sever > Role-Based Access Control > Roles (fasst Privileges zusammen)

Als Code:

kinit admin

ipa help commands

ipa group-add "sales"
ipa group-add "admin-sales"


ipa permission-add "My Perm Add User to group sales" \
    --right=write \
    --attrs=member \
    --bindtype=permission \
    --targetgroup=sales

ipa permission-add "My Perm Change User password sales" \
    --right=write \
    --attrs=krbpasswordexpiration \
    --attrs=krbprincipalkey \
    --attrs=passwordhistory \
    --attrs=sambalmpassword \
    --attrs=sambantpassword \
    --attrs=userpassword \
    --bindtype=permission \
    --memberof=sales \
    --type=user

ipa permission-add "My Perm Modify Users sales" \
    --right=write \
    --attrs=displayname \
    --attrs=givenname \
    --attrs=mail \
    --bindtype=permission \
    --memberof=sales \
    --type=user

ipa permission-add "My Perm Remove Users sales" \
    --right=delete \
    --bindtype=permission \
    --memberof=sales \
    --type=user

ipa permission-add "My Perm Unlock User sales" \
    --right=write \
    --attrs=krblastadminunlock \
    --attrs=krbloginfailedcount \
    --attrs=nsaccountlock \
    --bindtype=permission \
    --memberof=sales \
    --type=user

ipa privilege-add "My Priv User Administrators sales"

ipa privilege-add-permission "My Priv User Administrators sales" --permissions="My Perm Add User to group sales"
ipa privilege-add-permission "My Priv User Administrators sales" --permissions="My Perm Change User password sales"
ipa privilege-add-permission "My Priv User Administrators sales" --permissions="My Perm Modify Users sales"
ipa privilege-add-permission "My Priv User Administrators sales" --permissions="My Perm Remove Users sales"
ipa privilege-add-permission "My Priv User Administrators sales" --permissions="My Perm Unlock User sales"

ipa privilege-add-permission "My Priv User Administrators sales" --permissions="System: Add User to default group"
ipa privilege-add-permission "My Priv User Administrators sales" --permissions="System: Add Users"
ipa privilege-add-permission "My Priv User Administrators sales" --permissions="System: Change User password"
ipa privilege-add-permission "My Priv User Administrators sales" --permissions="System: Read UPG Definition"

ipa role-add "My Role User Administrator sales"
ipa role-add-member "My Role User Administrator sales" --groups="admin-sales"
ipa role-add-privilege "My Role User Administrator sales" --privileges="My Priv User Administrators sales"

Troubleshooting

Der Client nimmt neue Einstellungen nicht an

Es dauert etwas, bis die Regeln greifen. Hier hilft auch ein systemctl restart sssd; sss_cache --everything auf dem Client.

LDAP-Logging

tail -f /var/log/dirsrv/slapd-*/access

Could not chdir to home directory $HOME: No such file or directory
# as root:
authselect current
authselect select sssd with-sudo with-mkhomedir
authselect current
Bei ipa-server-install: IPv6 stack is enabled in the kernel but there is no interface that has ::1 address assigned. Add ::1 address resolution to ‚lo‘ interface. You might need to enable IPv6 on the interface ‚lo‘ in sysctl.conf.
/etc/sysctl.conf
net.ipv6.conf.lo.disable_ipv6 = 0

sysctl -p
Passwort des „admin“-Users zurücksetzen:
ldappasswd -ZZ -D 'cn=Directory Manager' -W -S uid=admin,cn=users,cn=accounts,dc=example,dc=com -H ldap://fqdn.example.com

Built on 2024-11-18