A developer does things that are at odds with a production deployment. Case in point: the FreeIPA assumes that it should be run on an ipa-client machine. But as a developer, I need to talk to remote FreeIPA servers. Here’s how to make the CLI work without performing a client install.

1. Set up Kerberos
edit /etc/krb5.conf (or put into an alternative)

[realms]
 IPA.CLOUDLAB.FREEIPA.ORG = {
  kdc = ipa.cloudlab.freeipa.org:88
  master_kdc = ipa.cloudlab.freeipa.org:88
  admin_server = ipa.cloudlab.freeipa.org:749
  default_domain = cloudlab.freeipa.org
  pkinit_anchors = FILE:/etc/ipa/ca.crt

[domain_realm]
 .cloudlab.freeipa.org = IPA.CLOUDLAB.FREEIPA.ORG
 cloudlab.freeipa.org = IPA.CLOUDLAB.FREEIPA.ORG


}

If you do not have write access to /etc, you can copy the remote one over

scp ipa.cloudlab.freeipa.org:/etc/krb5.conf .

KRB5_CONFIG=./krb5.conf

2. Copy over the ca.crt and install into the NSS database

scp ipa.cloudlab.freeipa.org:/etc/ipa/ca.crt .
sudo certutil -A -n 'IPA CA' -d /etc/pki/nssdb -t CT,, -a -i ca.crt

Note that I had done this before, and needed to remove the old IPA CA cert with:

sudo certutil -D -n 'IPA CA' -d /etc/pki/nssdb

There doesn’t appear to be an alternative. While NSS_DEFAULT_DB_TYPE is a standard environment variable, there does not seem to be a NSS_DEFAULT_DB variable.

3. Fetch the FreeIPA config file

 scp ipa.cloudlab.freeipa.org:/etc/ipa/default.conf ./ipa.conf

4. Run the ipa command, indicating that you should use an alternative configuration file. Use a fully qualified path or you get a nasty error.

  $ ipa -c $PWD/ipa.conf user-show ayoung
  User login: ayoung
  First name: Adam
  Last name: Young
  Home directory: /home/ayoung
  Login shell: /bin/sh
  Email address: ayoung@redhat.com
  UID: 1387400001
  GID: 1387400001
  Account disabled: False
  Password: True
  Member of groups: admins, ipausers, osprey, eagle, hawk, wheel
  Kerberos keys available: True