Security

Hi,

I have recently started to implement the ClearPass API and i am having an issue that the response body is not always the same as the documentation.

I have checked documentation both here https://developer.arubanetworks.com/cppm/reference/ and the API Explorer/api-docs directly in ClearPass.
I have tried across multiple ClearPass versions (6.10.7, 6.11.1, 6.11.13 and 6.12.4) with the same results. There are more available API endpoints in later versions 6.12 > 6.11 > 6.10, but all of them seem to be missing the secrets in response body. 

I am using an API client with:
Operating Mode = ClearPass REST API - Client will be used for API calls to ClearPass
Operator Profile = Super Administrator
Grant Type = Client credentials (grant_type=client_credentials)

API Endpoints where the response body contains secrets:
/api/auth-source (As expected)
/api/local-user (As expected, though only password hash)

API Endpoints where the response body does not contain secrets:
/api/network-device (expect "radius_secret": "string" and "tacacs_secret": "string". I receive enpty strings ie. "radius_secret": "")
/api/api-client (expect "client_secret": "string". I receive enpty strings ie. "client_secret": "")
/api/device (expect "password": "string". "password" is not even returned, i do get "no_password": "1")

Im wondering if I am doing something wrong or if this is an error on the ClearPass side.

My highest priority is the RADIUS/TACACS PSK in /api/network-device

If anyone is using the API and is able to fetch secrets, please let me know what i am doing wrong :)

Hi Mathias.

The shared secrets are write only, so you wont be able to get them from the API. This is the same with Guests and Devices.

The way i had to do it for automating shared secrets, is with web scraping and automating the export via the GUI the programmatically go through the XML. 

For Guest users and devices there is no way to automate this. Even if you go into the SQL database directly, the password is hashed - Only way to migrate users for example is with the guest DB backup option which you can import elsewhere but still cannot view or read the guest and device passwords.

Hi,

I have recently started to implement the ClearPass API and i am having an issue that the response body is not always the same as the documentation.

I have checked documentation both here https://developer.arubanetworks.com/cppm/reference/ and the API Explorer/api-docs directly in ClearPass.
I have tried across multiple ClearPass versions (6.10.7, 6.11.1, 6.11.13 and 6.12.4) with the same results. There are more available API endpoints in later versions 6.12 > 6.11 > 6.10, but all of them seem to be missing the secrets in response body. 

I am using an API client with:
Operating Mode = ClearPass REST API - Client will be used for API calls to ClearPass
Operator Profile = Super Administrator
Grant Type = Client credentials (grant_type=client_credentials)

API Endpoints where the response body contains secrets:
/api/auth-source (As expected)
/api/local-user (As expected, though only password hash)

API Endpoints where the response body does not contain secrets:
/api/network-device (expect "radius_secret": "string" and "tacacs_secret": "string". I receive enpty strings ie. "radius_secret": "")
/api/api-client (expect "client_secret": "string". I receive enpty strings ie. "client_secret": "")
/api/device (expect "password": "string". "password" is not even returned, i do get "no_password": "1")

Im wondering if I am doing something wrong or if this is an error on the ClearPass side.

My highest priority is the RADIUS/TACACS PSK in /api/network-device

If anyone is using the API and is able to fetch secrets, please let me know what i am doing wrong :)

Hi Ben!

That is sad to hear. Very strange of HPE to decide that the API is unable to read secrets, especially for NADs since the GUI xml export exists and can do it when a password is provided...
Thanks for the info!

I created a feature request on innovationzone, hopefully the API will be expanded in the near future.
Allow API to return passwords/secrets in response body https://innovationzone.arubanetworking.hpe.com/ideas/NAC-I-2241

Hi Mathias.

The shared secrets are write only, so you wont be able to get them from the API. This is the same with Guests and Devices.

The way i had to do it for automating shared secrets, is with web scraping and automating the export via the GUI the programmatically go through the XML. 

For Guest users and devices there is no way to automate this. Even if you go into the SQL database directly, the password is hashed - Only way to migrate users for example is with the guest DB backup option which you can import elsewhere but still cannot view or read the guest and device passwords.

Hi,

I have recently started to implement the ClearPass API and i am having an issue that the response body is not always the same as the documentation.

I have checked documentation both here https://developer.arubanetworks.com/cppm/reference/ and the API Explorer/api-docs directly in ClearPass.
I have tried across multiple ClearPass versions (6.10.7, 6.11.1, 6.11.13 and 6.12.4) with the same results. There are more available API endpoints in later versions 6.12 > 6.11 > 6.10, but all of them seem to be missing the secrets in response body. 

I am using an API client with:
Operating Mode = ClearPass REST API - Client will be used for API calls to ClearPass
Operator Profile = Super Administrator
Grant Type = Client credentials (grant_type=client_credentials)

API Endpoints where the response body contains secrets:
/api/auth-source (As expected)
/api/local-user (As expected, though only password hash)

API Endpoints where the response body does not contain secrets:
/api/network-device (expect "radius_secret": "string" and "tacacs_secret": "string". I receive enpty strings ie. "radius_secret": "")
/api/api-client (expect "client_secret": "string". I receive enpty strings ie. "client_secret": "")
/api/device (expect "password": "string". "password" is not even returned, i do get "no_password": "1")

Im wondering if I am doing something wrong or if this is an error on the ClearPass side.

My highest priority is the RADIUS/TACACS PSK in /api/network-device

If anyone is using the API and is able to fetch secrets, please let me know what i am doing wrong :)

Don't spell it out like this, as the result may be that passwords/secrets are removed from the XML export ;-)

Some of these design decisions may be based on (security) certifications or interpretations of those. It's hard to make it fit everyone's preference.

In practice, you may have the secret somewhere already and just update it to what it should be. Because you also need to have the same in your NAD configured. Or use the XML export once to create such an overview and start working from there.

For Guest passwords, those are if I remember correctly stored as hashes by default, so can't even be displayed if you would like to. This is to comply to security rules that indicate that you should never store passwords in plaintext or with reversible encryption. But you can turn that off in the Guest configuration:

That will change the behavior to store guest passwords in a reversible way so you can access them. If you had that disabled, you may try again with this enabled and the view-password permission on the API account.

Hi Ben!

That is sad to hear. Very strange of HPE to decide that the API is unable to read secrets, especially for NADs since the GUI xml export exists and can do it when a password is provided...
Thanks for the info!

I created a feature request on innovationzone, hopefully the API will be expanded in the near future.
Allow API to return passwords/secrets in response body https://innovationzone.arubanetworking.hpe.com/ideas/NAC-I-2241

Hi Mathias.

The shared secrets are write only, so you wont be able to get them from the API. This is the same with Guests and Devices.

The way i had to do it for automating shared secrets, is with web scraping and automating the export via the GUI the programmatically go through the XML. 

For Guest users and devices there is no way to automate this. Even if you go into the SQL database directly, the password is hashed - Only way to migrate users for example is with the guest DB backup option which you can import elsewhere but still cannot view or read the guest and device passwords.

Hi,

I have recently started to implement the ClearPass API and i am having an issue that the response body is not always the same as the documentation.

I have checked documentation both here https://developer.arubanetworks.com/cppm/reference/ and the API Explorer/api-docs directly in ClearPass.
I have tried across multiple ClearPass versions (6.10.7, 6.11.1, 6.11.13 and 6.12.4) with the same results. There are more available API endpoints in later versions 6.12 > 6.11 > 6.10, but all of them seem to be missing the secrets in response body. 

I am using an API client with:
Operating Mode = ClearPass REST API - Client will be used for API calls to ClearPass
Operator Profile = Super Administrator
Grant Type = Client credentials (grant_type=client_credentials)

API Endpoints where the response body contains secrets:
/api/auth-source (As expected)
/api/local-user (As expected, though only password hash)

API Endpoints where the response body does not contain secrets:
/api/network-device (expect "radius_secret": "string" and "tacacs_secret": "string". I receive enpty strings ie. "radius_secret": "")
/api/api-client (expect "client_secret": "string". I receive enpty strings ie. "client_secret": "")
/api/device (expect "password": "string". "password" is not even returned, i do get "no_password": "1")

Im wondering if I am doing something wrong or if this is an error on the ClearPass side.

My highest priority is the RADIUS/TACACS PSK in /api/network-device

If anyone is using the API and is able to fetch secrets, please let me know what i am doing wrong :)

Hi Herman!

Lets hope someone at HPE will read this and interpret it in the correct way to enable more features instead of removing existing capabilities 😅

The point of an API in my opinion is to be able to automate anything you can do manually, so all features/options/settings in the GUI should be accessible via API.

Yes, of course we have the NAD PSKs saved in an external keystore as well, so it is possible for us to re-generate the config if needed with API. But if the API allowed it, it would be possible to create config checkpoints that you could restore much faster compared to a full config backup. You could also validate all config with automation, that is not possible with the current API. 

Don't spell it out like this, as the result may be that passwords/secrets are removed from the XML export ;-)

Some of these design decisions may be based on (security) certifications or interpretations of those. It's hard to make it fit everyone's preference.

In practice, you may have the secret somewhere already and just update it to what it should be. Because you also need to have the same in your NAD configured. Or use the XML export once to create such an overview and start working from there.

For Guest passwords, those are if I remember correctly stored as hashes by default, so can't even be displayed if you would like to. This is to comply to security rules that indicate that you should never store passwords in plaintext or with reversible encryption. But you can turn that off in the Guest configuration:

That will change the behavior to store guest passwords in a reversible way so you can access them. If you had that disabled, you may try again with this enabled and the view-password permission on the API account.

Hi Ben!

That is sad to hear. Very strange of HPE to decide that the API is unable to read secrets, especially for NADs since the GUI xml export exists and can do it when a password is provided...
Thanks for the info!

I created a feature request on innovationzone, hopefully the API will be expanded in the near future.
Allow API to return passwords/secrets in response body https://innovationzone.arubanetworking.hpe.com/ideas/NAC-I-2241

Hi Mathias.

The shared secrets are write only, so you wont be able to get them from the API. This is the same with Guests and Devices.

The way i had to do it for automating shared secrets, is with web scraping and automating the export via the GUI the programmatically go through the XML. 

For Guest users and devices there is no way to automate this. Even if you go into the SQL database directly, the password is hashed - Only way to migrate users for example is with the guest DB backup option which you can import elsewhere but still cannot view or read the guest and device passwords.

Hi,

I have recently started to implement the ClearPass API and i am having an issue that the response body is not always the same as the documentation.

I have checked documentation both here https://developer.arubanetworks.com/cppm/reference/ and the API Explorer/api-docs directly in ClearPass.
I have tried across multiple ClearPass versions (6.10.7, 6.11.1, 6.11.13 and 6.12.4) with the same results. There are more available API endpoints in later versions 6.12 > 6.11 > 6.10, but all of them seem to be missing the secrets in response body. 

I am using an API client with:
Operating Mode = ClearPass REST API - Client will be used for API calls to ClearPass
Operator Profile = Super Administrator
Grant Type = Client credentials (grant_type=client_credentials)

API Endpoints where the response body contains secrets:
/api/auth-source (As expected)
/api/local-user (As expected, though only password hash)

API Endpoints where the response body does not contain secrets:
/api/network-device (expect "radius_secret": "string" and "tacacs_secret": "string". I receive enpty strings ie. "radius_secret": "")
/api/api-client (expect "client_secret": "string". I receive enpty strings ie. "client_secret": "")
/api/device (expect "password": "string". "password" is not even returned, i do get "no_password": "1")

Im wondering if I am doing something wrong or if this is an error on the ClearPass side.

My highest priority is the RADIUS/TACACS PSK in /api/network-device

If anyone is using the API and is able to fetch secrets, please let me know what i am doing wrong :)

mathias,

If you want to feedback these requests into product development, it's better to use the formal path:

• if you feel this is a bug: open a TAC case
• if this is a feature request, raise an Innovation Zone request; let others vote for it; and/or work with your local SE

This message in the forum may be picked up, but it's not actively monitored for feature requests; and feature requests work better if there is an actual customer bound to it.

Hi Herman!

Lets hope someone at HPE will read this and interpret it in the correct way to enable more features instead of removing existing capabilities 😅

The point of an API in my opinion is to be able to automate anything you can do manually, so all features/options/settings in the GUI should be accessible via API.

Yes, of course we have the NAD PSKs saved in an external keystore as well, so it is possible for us to re-generate the config if needed with API. But if the API allowed it, it would be possible to create config checkpoints that you could restore much faster compared to a full config backup. You could also validate all config with automation, that is not possible with the current API. 

Don't spell it out like this, as the result may be that passwords/secrets are removed from the XML export ;-)

Some of these design decisions may be based on (security) certifications or interpretations of those. It's hard to make it fit everyone's preference.

In practice, you may have the secret somewhere already and just update it to what it should be. Because you also need to have the same in your NAD configured. Or use the XML export once to create such an overview and start working from there.

For Guest passwords, those are if I remember correctly stored as hashes by default, so can't even be displayed if you would like to. This is to comply to security rules that indicate that you should never store passwords in plaintext or with reversible encryption. But you can turn that off in the Guest configuration:

That will change the behavior to store guest passwords in a reversible way so you can access them. If you had that disabled, you may try again with this enabled and the view-password permission on the API account.

Hi Ben!

That is sad to hear. Very strange of HPE to decide that the API is unable to read secrets, especially for NADs since the GUI xml export exists and can do it when a password is provided...
Thanks for the info!

I created a feature request on innovationzone, hopefully the API will be expanded in the near future.
Allow API to return passwords/secrets in response body https://innovationzone.arubanetworking.hpe.com/ideas/NAC-I-2241

Hi Mathias.

The shared secrets are write only, so you wont be able to get them from the API. This is the same with Guests and Devices.

The way i had to do it for automating shared secrets, is with web scraping and automating the export via the GUI the programmatically go through the XML. 

For Guest users and devices there is no way to automate this. Even if you go into the SQL database directly, the password is hashed - Only way to migrate users for example is with the guest DB backup option which you can import elsewhere but still cannot view or read the guest and device passwords.

Hi,

I have recently started to implement the ClearPass API and i am having an issue that the response body is not always the same as the documentation.

I have checked documentation both here https://developer.arubanetworks.com/cppm/reference/ and the API Explorer/api-docs directly in ClearPass.
I have tried across multiple ClearPass versions (6.10.7, 6.11.1, 6.11.13 and 6.12.4) with the same results. There are more available API endpoints in later versions 6.12 > 6.11 > 6.10, but all of them seem to be missing the secrets in response body. 

I am using an API client with:
Operating Mode = ClearPass REST API - Client will be used for API calls to ClearPass
Operator Profile = Super Administrator
Grant Type = Client credentials (grant_type=client_credentials)

API Endpoints where the response body contains secrets:
/api/auth-source (As expected)
/api/local-user (As expected, though only password hash)

API Endpoints where the response body does not contain secrets:
/api/network-device (expect "radius_secret": "string" and "tacacs_secret": "string". I receive enpty strings ie. "radius_secret": "")
/api/api-client (expect "client_secret": "string". I receive enpty strings ie. "client_secret": "")
/api/device (expect "password": "string". "password" is not even returned, i do get "no_password": "1")

Im wondering if I am doing something wrong or if this is an error on the ClearPass side.

My highest priority is the RADIUS/TACACS PSK in /api/network-device

If anyone is using the API and is able to fetch secrets, please let me know what i am doing wrong :)