Security in NoMAD

As an application dealing with passwords and certificates, NoMAD takes security very seriously. Here are some notes to give you a better understanding of what NoMAD does with your secrets.

General Thoughts

NoMAD itself doesn’t do any of the heavy lifting as far as signing in to Active Directory and getting you SSO access. The interaction with AD is all done via Kerberos and LDAP, Heimdal Kerberos, and OpenLDAP. NoMAD uses the versions of those tools that ship with macOS.

Source Available

Since NoMAD is an open source project, all of the source code used for it is publicly available. You are more than welcome to inspect the source, run it through a security scanner, or otherwise ensure that we’re doing things in the proper way.

Please let us know if you have any concerns about particular lines of code— we want to make sure that NoMAD is just as secure as we say it is.


While most of NoMAD is written in Swift, there is no easy way to directly interact with the Heimdal Kerberos APIs on macOS in Swift. Because of that, an Objective-C bridging header is used to mix the two languages. Whenever you are asked for a password, it’s done via a secure text field and never written out anywhere. The password is then used with the Heimdal APIs and Objective-C to do gss_aapl_initial_cred() and get a TGT for the user. When changing passwords, the same process is followed using the Heimdal APIs to do gss_aapl_change_password().

The password is never piped to kinit or other Kerberos tools.

When NoMAD is finished with your password, the variable is blanked to remove any trace from memory as quickly as possible.

Keychain Usage

If instructed, NoMAD will put the user’s password into the local Keychain. This is done through the use of SecKeychainAddGenericPassword() and other SecKeychain methods. The password is stored in the default keychain and will be removed if the user selects “Log Out” from the menu.

If a password is present in the Keychain, NoMAD will use that password on launch to get Kerberos tickets. If the password is unable to authenticate the user, NoMAD deletes the password from the keychain so that it won’t ever accidentally lock you out by attempting to sign in with an incorrect password.

Active Directory Security

NoMAD  does not require any security settings to be changed in Active Directory. NoMAD only uses SASL-authenticated binds when interacting with AD. By default, NoMAD uses the user’s Kerberos ticket to encrypt any LDAP traffic with AD. For more security, starting with version 1.0.5, NoMAD can be configured to use SSL in addition to LDAP connections to AD.

User Space

NoMAD runs in user space, not as root. As such, it has no more privileges than the currently logged in user does. NoMAD’s functionality does not differ between admin and non-admin users.


All of the application preferences can be set using configuration profiles either installed locally or from an MDM service. Setting the preferences in this way prevents a user from being able to change them.


Similarly to passwords, NoMAD does not send a private key across the wire. The private key used for generating your CSR never leaves the Keychain. The process is done entirely within NoMAD using the SecKeychain and SecCertificate APIs.

The private keys are marked as non-exportable by default; however, you can use a preference to change this.

When sending the CSR to the Windows CA, Kerberos authentication is used, and the CSR is sent via SSL. Even though nothing in the CSR is sensitive, good data-in-motion hygiene is respected. The resulting signed public key is retrieved using Kerberos and SSL, and then matched up with the private key in the Keychain.


The project in the repository has been set to Allow Arbitrary Loads for App Transport Security. You can change this flag in the Info tab of the project in Xcode.

This setting allows for self-signed but specifically trusted certificates to be used, because many Windows CAs use a self-signed certificate root that all machines in the organization trust. In that situation, NoMAD is not able to get a x509 identity, even if the root certificate was explicitly trusted in the user’s Keychain.

You can remove this flag before compiling, but keep in mind that if you’re not using a publicly trusted certificate you’re likely to encounter issues when attempting to get a certificate for a user. If you don’t want to use the certificate functionality within NoMAD, then no other parts of NoMAD are impacted by changing SSL settings.

Network Connections

NoMAD does not listen for any incoming connections. All communications from NoMAD are outbound queries for DNS, LDAP, Kerberos and some web connections for certificates and other integrations that have been configured in the NoMAD preferences.


Currently NoMAD is unable to be sandboxed on OS X/macOS due to a few different features:

  1. The function being used to sleep the screen is not allowed inside a sandbox.
  2. If you want to sync the AD password with the local password, NoMAD needs to be able to change the local Keychain password. It does this using a private API SecKeychainChangePassword(). If/when a public API becomes available that accomplishes the same task, we’ll move to that.
  3. The aforementioned App Transport Security flag.