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.
- BIG-IP 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"
]
}
}
}
Configuring BIG-IP authentication methods¶
In this example, we show how to configure RADIUS, LDAP, and TACACS authentication in a BIG-IP 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 BIG-IP DO 1.13.
For more information on options and BIG-IP DO usage, see Authentication and the subsequent entries in the Schema Reference.
Note
We updated this example for the following:
- BIG-IP DO 1.17 includes a CA certificate for LDAP using the new sslCaCert property.
- BIG-IP 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 BIG-IP DO information and BIG-IP DO usage. Also see the LDAP example Reference CA cert via URL.
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 BIG-IP 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 BIG-IP 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": "192.0.2.60",
"port": 1811,
"secret": "mySecret"
},
"secondary": {
"server": "my.second.server",
"secret": "anotherSecret",
"port": 1888
}
}
},
"ldap": {
"bindDn": "searchingName",
"bindPassword": "pass1w0rd",
"bindTimeout": 40,
"checkBindPassword": false,
"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",
"192.0.2.60",
"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",
"192.0.2.60",
"FE80:0000:0000:0000:0202:B3FF:FE1E:8329"
],
"service": "ppp"
}
}
}
}
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 BIG-IP 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"
}
}
}
Configuring SSHD settings in a declaration¶
In this example, we show how you can configure SSHD (SSH daemon) settings in a BIG-IP 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 BIG-IP Declarative Onboarding declaration.
New in BIG-IP DO 1.15
BIG-IP 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"
],
"kexAlgorithms": [
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521"
],
"maxAuthTries": 10,
"maxStartups": "5",
"protocol": 1
}
}
}
Updating the TLS/SSL Device Certificate in a declaration¶
This example declaration shows how you can create/upload a device certificate in a BIG-IP 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:
- BIG-IP BIG-IP 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), BIG-IP DO reboots the BIG-IP device in order to include the updated certificate
- BIG-IP DO makes backups of the certificates and keys in those directories before overwriting the existing certificate and key
- Like other settings in BIG-IP DO, if a subsequent declaration is posted without the certificate, BIG-IP DO will restore the certificate that was there when it first ran.
See DeviceCertificate in the schema reference for more information and usage. .. NOTE:: When you set property “updateTrustCerts”: true, it will update the trusted certificate stores when the device certificate is updated. This property “updateTrustCerts” is supported on DO 1.41 and later.
{
"schemaVersion": "1.41.0",
"class": "Device",
"Common": {
"class": "Tenant",
"hostname": "bigip.example.com",
"deviceCertificate": {
"class": "DeviceCertificate",
"certificate": {
"base64": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCkY1IEZBS0UgQ0VSVElGSUNBVEUKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ=="
},
"privateKey": {
"base64": "LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpGNSBGQUtFIFBSSVZBVEUgS0VZCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0t"
},
"updateTrustCerts": true
}
}
}
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 BIG-IP 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"
}
}
}
Configuring a BIG-IP password policy¶
This example shows how you can use the PasswordPolicy class introduced in BIG-IP DO 1.33. This class allows you to set a variety of parameters to define a password policy.
See PasswordPolicy in the schema reference for specific details on each of the parameters in the PasswordPolicy class, as well as DO usage.
{
"schemaVersion": "1.33.0",
"class": "Device",
"async": true,
"Common": {
"class": "Tenant",
"myPasswordPolicy": {
"class": "PasswordPolicy",
"expirationWarningDays": 1,
"minLength": 15,
"minDurationDays": 14,
"maxDurationDays": 60,
"lockoutDurationSeconds": 120,
"maxLoginFailures": 10,
"passwordMemory": 8,
"policyEnforcementEnabled": true,
"requiredUppercase": 2,
"requiredLowercase": 3,
"requiredNumeric": 4,
"requiredSpecial": 5
}
}
}
Referencing a URL in the sslCaCert property of Authentication_ldap¶
This example shows how you can reference an SSL CA certificate by URL in the sslCaCert property of the Authentication_ldap class in BIG-IP DO 1.38 and later. This class allows you reference a certificate rather than have the entire base64 value in the declaration.
See Authentication_ldap in the schema reference for more information and DO usage.
{
"class": "Device",
"schemaVersion": "1.38.0",
"async": true,
"Common": {
"class": "Tenant",
"test_item-foo.2345678901234567890123456789012345": {
"class": "Authentication",
"enabledSourceType": "ldap",
"ldap": {
"bindTimeout": 40,
"checkBindPassword": true,
"checkRemoteRole": true,
"idleTimeout": 20,
"ignoreAuthInfoUnavailable": true,
"ignoreUnknownUser": true,
"port": 654,
"searchScope": "base",
"searchTimeout": 687,
"servers": [
"a.host.com",
"192.0.2.10",
"FE80:0000:0000:0000:0202:B3FF:FE1E:8329"
],
"ssl": "enabled",
"sslCaCert": {
"certificate": {
"url": "https://exampleUrl/cert"
}
},
"sslCheckPeer": true,
"sslCiphers": [
"ECDHE-RSA-AES128-CBC-SHA",
"ECDHE-RSA-AES128-SHA256"
],
"userTemplate": "uid=%s,ou=people,dc=siterequest,dc=com",
"version": 2
}
}
}
}