Authentication Examples

This section contains example declarations concerning authentication.

Adding public SSH keys to a declaration

In this example, we are adding public SSH keys to the root user and a guestUser. This can provide a higher level of security and easier automation.

Important notes about using the keys property

  • Only the root user’s primary key (noted by the Host Processor Superuser), in authorized_keys will be preserved. All other keys configured prior to running this declaration, WILL BE DELETED.
  • If the keys field is left empty it will default to an empty array. This means leaving it empty will clear the authorized_keys file, except for the root’s master key.
  • For non-root users, the path to the authorized_keys is /home/{username}/.ssh/authorized_keys.
  • For root, the path is /root/.ssh/authorized_keys.
  • DO will set the non-root user’s .ssh directory permissions to 700, with the authorized_keys permissions set to 600.
{
    "schemaVersion": "1.0.0",
    "class": "Device",
    "async": true,
    "Common": {
        "class": "Tenant",
        "hostname": "bigip.example.com",
        "root": {
            "class": "User",
            "userType": "root",
            "oldPassword": "examplePass",
            "newPassword": "examplePass",
            "keys": [
                "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCwHJLJY+/U/ioAAAADAQABAAACAQCwHJLJY+z0Rb85in7Ean6JS2J9dzo1nSssm7ZyQvGgc1e7EVtztbVpHThsvw92+1hx9wlSogXN6Co5zrtqlN8/mvlQkRRQ+sp2To8PcSMeEVI+TqBOg6BWbwwNQLz9/eUJq2o4vBfSpsn7GSDIf6C3F9EahRPGCR/z0kw5GZob3Q== test2",
                "ssh-rsa AAAAB3NzaC1yc2EAu2Gr14xRiVLnG8KxNp2fO1/U/ioAz0Rb85in7Ean6JS2J9dzo1nSssm7ZyQvGgc1e7EVtztbVpHThsvw92+/mvlQkRRQ+sp2To8PcSMeEVI+TqBOg6BWbwwNQLzu2Gr14xRiVLnG8KxNp2fO19/eUJq2o4vBfSpsn7GSDIf6C3F9EahRPGCR/z0kw5GZob3Q== test"
            ]
        },
        "guestUser": {
            "class": "User",
            "userType": "regular",
            "password": "guestNewPass1",
            "partitionAccess": {
                "Common": {
                    "role": "guest"
                }
            },
            "keys": [
                "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCwHJLJY+/U/ioAAAADAQABAAACAQCwHJLJY+z0Rb85in7Ean6JS2J9dzo1nSssm7ZyQvGgc1e7EVtztbVpHThsvw92+1hx9wlSogXN6Co5zrtqlN8/mvlQkRRQ+sp2To8PcSMeEVI+TqBOg6BWbwwNQLz9/eUJq2o4vBfSpsn7GSDIf6C3F9EahRPGCR/z0kw5GZob3Q== test2",
                "ssh-rsa AAAAB3NzaC1yc2EAu2Gr14xRiVLnG8KxNp2fO1/U/ioAz0Rb85in7Ean6JS2J9dzo1nSssm7ZyQvGgc1e7EVtztbVpHThsvw92+/mvlQkRRQ+sp2To8PcSMeEVI+TqBOg6BWbwwNQLzu2Gr14xRiVLnG8KxNp2fO19/eUJq2o4vBfSpsn7GSDIf6C3F9EahRPGCR/z0kw5GZob3Q== test"
            ]
        }
    }
}

Back to top


Configuring BIG-IP authentication methods

In this example, we show how to configure RADIUS, LDAP, and TACACS authentication in a Declarative Onboarding declaration using the Authentication class. The authentication class can (but does not have to) contain multiple authentication method subclasses, but only one can be enabled at a time using the enableSourceType property (which matches the BIG-IP UI behavior).

This example declaration contains all three authentication methods with the enableSourceType property set to radius. It also includes the SSL options for LDAP introduced in DO 1.13.

For more information on options and DO usage, see Authentication and the subsequent entries in the Schema Reference.

Note

We updated this example for the following:
- DO 1.17 includes a CA certificate for LDAP using the new sslCaCert property.
- DO 1.21 includes the ability to enable or disable LDAP referral chasing using the new referrals Boolean (BIG-IP 15.1 and later only).
See Authentication_ldap in the Schema Reference for DO information and DO usage.
IMPORTANT: If you attempt to use the example declaration on a previous version that does not include one of these features, it will fail. You can remove the lines highlighted in yellow for previous versions of DO.

In the following declaration snippet we show only the classes related to authentication. You can use this class as a part of a larger Declarative Onboarding declaration.

{
    "schemaVersion": "1.7.0",
    "async": true,
    "class": "Device",
    "label": "LDAP, RADIUS, and TACACS auth",
    "Common": {
        "class": "Tenant",
        "myAuth": {
            "class": "Authentication",
            "enabledSourceType": "radius",
            "fallback": true,
            "remoteUsersDefaults": {
                "partitionAccess": "all",
                "terminalAccess": "tmsh",
                "role": "resource-admin"
            },
            "radius": {
                "serviceType": "call-check",
                "servers": {
                    "primary": {
                        "server": "1.2.3.4",
                        "port": 1811,
                        "secret": "mySecret"
                    },
                    "secondary": {
                        "server": "my.second.server",
                        "secret": "anotherSecret",
                        "port": 1888
                    }
                }
            },
            "ldap": {
                "bindDn": "searchingName",
                "bindPassword": "pass1w0rd",
                "bindTimeout": 40,
                "checkBindPassword": true,
                "checkRemoteRole": true,
                "filter": "filter",
                "groupDn": "groupName",
                "groupMemberAttribute": "attribute",
                "idleTimeout": 20,
                "ignoreAuthInfoUnavailable": true,
                "ignoreUnknownUser": true,
                "loginAttribute": "attributeToLogin",
                "port": 654,
                "referrals": true,
                "searchScope": "base",
                "searchBaseDn": "searchName",
                "searchTimeout": 687,
                "servers": [
                    "my.host.com",
                    "1.2.3.4",
                    "FE80:0000:0000:0000:0202:B3FF:FE1E:8329"
                ],
                "ssl": "enabled",
                "sslCaCert": {
                    "certificate": {
                        "base64": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCkY1IEZBS0UgQ0VSVElGSUNBVEUKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ=="
                    }
                },
                "sslCheckPeer": true,
                "sslCiphers": [
                    "ECDHE-RSA-AES128-GCM-SHA256",
                    "ECDHE-RSA-AES128-CBC-SHA",
                    "ECDHE-RSA-AES128-SHA256"
                ],
                "userTemplate": "uid=%s,ou=people,dc=siterequest,dc=com",
                "version": 2
            },
            "tacacs": {
                "accounting": "send-to-first-server",
                "authentication": "use-first-server",
                "debug": false,
                "encryption": true,
                "protocol": "ip",
                "secret": "aSecret1",
                "servers": [
                    "my.host.com",
                    "1.2.3.4",
                    "FE80:0000:0000:0000:0202:B3FF:FE1E:8329"
                ],
                "service": "ppp"
            }
        }
    }
}

Back to top


Configuring Remote Roles for authentication

In this example, we show how to configure a remote role for authentication using the RemoteAuthRole class. See RemoteAuthRole Class in the Schema reference for a description of each of the parameters for this class.

Important: The BIG-IP only allows one role per user for each partition/tenant. Because some remote servers allow multiple user roles, the BIG-IP uses the lineOrder parameter to choose one of the conflicting roles for the user at login time. In these cases, the system chooses the role with the lowest line-order number. See Line Order in the BIG-IP documentation for more information and examples.

In the following declaration snippet we show only the classes related to remote auth roles. You can use this class as a part of a larger Declarative Onboarding declaration.

{
    "schemaVersion": "1.7.0",
    "class": "Device",
    "async": true,
    "Common": {
        "class": "Tenant",
        "TEAM1": {
            "class": "RemoteAuthRole",
            "attribute": "memberOF=CN=Team-1,add-ldap-path",
            "console": "tmsh",
            "lineOrder": 925,
            "role": "admin",
            "remoteAccess": false,
            "userPartition": "all"
        },
        "TEAM2": {
            "class": "RemoteAuthRole",
            "attribute": "memberOF=CN=Team-2,add-ldap-path",
            "console": "tmsh",
            "lineOrder": 940,
            "role": "guest",
            "remoteAccess": true,
            "userPartition": "all"
        }
    }
}

Back to top


Configuring SSHD settings in a declaration

In this example, we show how you can configure SSHD (SSH daemon) settings in a Declarative Onboarding declaration. For usage and options, see SSHD in the Schema Reference.

In the following declaration, we show only the SSHD class. You can use this class as a part of a larger Declarative Onboarding declaration.

New in DO 1.15
Declarative Onboarding v1.15 and later includes the ability to set the source IP addresses that are allowed to log into the system, using the new allow property. You can allow all addresses by using the all value, or disallow all addresses using the none value; otherwise, you can specify an array of IP address as shown in the updated example.

Important

If you attempt to use the following declaration on a version prior to 1.15, it will fail. To use the example on a previous version, delete the allow property and IP addresses (the hightlighted lines)

    {
    "schemaVersion": "1.8.0",
    "class": "Device",
    "async": false,
    "label": "Configuring SSHD settings",
    "Common": {
        "class": "Tenant",
        "sshSettings": {
            "class": "SSHD",
            "allow": [
                "10.0.0.1",
                "10.0.1.0/28",
                "192.168.1.*"
            ],
            "banner": "Banner to display",
            "inactivityTimeout": 123,
            "ciphers": [
                "aes128-ctr",
                "aes192-ctr",
                "aes256-ctr"
            ],
            "loginGraceTime": 100,
            "MACS": [
                "hmac-sha1",
                "hmac-ripemd160",
                "hmac-md5"
            ],
            "maxAuthTries": 10,
            "maxStartups": "5",
            "protocol": 1
        }
    }
}

Back to top


Updating the TLS/SSL Device Certificate in a declaration

This example declaration shows how you can create/upload a device certificate in a Declarative Onboarding declaration. The BIG-IP system uses the device certificate to authenticate access to the Configuration utility and to accommodate device-to-device communication processes, such as configuration synchronization.

For more information and how this process works manually, see the KB article Updating a self-signed SSL device certificate on a BIG-IP system.

A couple of things to note when including certificates and keys in a declaration:

  • DO always writes to /config/httpd/conf/ssl.crt/server.crt and ssl.key/server.key
  • If the device certificate is updated (that is, if the certificate in the declaration does not match the certificate in those directories), DO reboots the BIG-IP device in order to include the updated certificate
  • DO makes backups of the certificates and keys in those directories before overwriting the existing certificate and key
  • Like other settings in DO, if a subsequent declaration is posted without the certificate, DO will restore the certificate that was there when it first ran.

See DeviceCertificate in the schema reference for more information and usage.

{
    "schemaVersion": "1.0.0",
    "class": "Device",
    "Common": {
        "class": "Tenant",
        "hostname": "bigip.example.com",
        "deviceCertificate": {
            "class": "DeviceCertificate",
            "certificate": {
                "base64": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCkY1IEZBS0UgQ0VSVElGSUNBVEUKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ=="
            },
            "privateKey": {
                "base64": "LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpGNSBGQUtFIFBSSVZBVEUgS0VZCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0t"
            }
        }
    }
}

Back to top


Using variables in some remote role properties

This example shows how you can use variable expressions for some of the properties in the RemoteAuthRole class (see Configuring Remote Roles for authentication for the example without variables). This allows you to reference variables that you defined in your AAA system in a Declarative Onboarding declaration.

There are two important notes for using this feature:

  • When you use variables, they MUST start with %.
  • You can currently use variables with the console, role, and userPartition properties.

See RemoteAuthRole Class in the schema reference for more information and usage for RemoteAuthRole.

{
    "schemaVersion": "1.17.0",
    "class": "Device",
    "async": true,
    "Common": {
        "class": "Tenant",
        "remoteAuthRole": {
            "class": "RemoteAuthRole",
            "attribute": "F5-LTM-User-Info-1=rad-admins",
            "console": "%F5-LTM-User-Shell",
            "lineOrder": 1001,
            "remoteAccess": true,
            "role": "%F5-LTM-User-Role",
            "userPartition": "%F5-LTM-User-Partition"
        }
    }
}

Back to top