Fetching a command control rule via REST with 3.5

According to the REST API for PAM 3.5, a GET of /rest/cmdctrl/Policy/rule/{key} will get details of a particular rule. Consider the following output for a GET of /rest/cmdctrl/Policies:

{
  "vrm": "3.5.0-3",
  "status": 200,
  "message": "OK",
  "CCTree": {
    "id": 0,
    "Rule": {
      "id": 1,
      "Rule": [
        {
          "id": 205,
          "key": 2,
          "name": "UNIX (ssh)",
          "type": 0,
          "disabled": 0,
          "ref": 1,
          "Rule": [
            {
              "id": 221,
              "key": 16,
              "name": "PAM Servers",
              "type": 0,
              "disabled": 0,
              "ref": 1,
              "Rule": [
                {
                  "id": 212,
                  "key": 9,
                  "name": "pam001 PAM Framework Manager",
                  "type": 0,
                  "disabled": 0,
                  "ref": 1
                },
                {
                  "id": 213,
                  "key": 10,
                  "name": "pam002 PAM UNIX Agent",
                  "type": 0,
                  "disabled": 0,
                  "ref": 1
                },

So what is {key} in /rest/cmdctrl/Policy/rule/{key}? Should I "GET /rest/cmdctrl/Policy/rule/10" to get info on "pam002 PAM UNIX Agent" or "GET /rest/cmdctrl/Policy/rule/213"? I have tried both and get back:

{
  "vrm": "3.5.0-3",
  "status": 404,
  "message": "Unable to find the cmdctrl object(s)."
}
  • I tried the GET against our PAM 3.2 server and it worked. So, something seems to be off with our installation of 3.5.

  • I'm thinking if you try 'key' as 16, 9, or 10 that it will find the cmdctrl object. I suspect you are trying with the 'id' and not the 'key' attribute. I did the exact same thing as well before.

    Let me know if that did the trick or if there is some other thing that could be an issue.
  • I'm thinking if you try 'key' as 16, 9, or 10 that it will find the cmdctrl object. I suspect you are trying with the 'id' and not the 'key' attribute. I did the exact same thing as well before.

    Let me know if that did the trick or if there is some other thing that could be an issue.
  • I'm thinking if you try 'key' as 16, 9, or 10 that it will find the cmdctrl object. I suspect you are trying with the 'id' and not the 'key' attribute. I did the exact same thing as well before.

    Let me know if that did the trick or if there is some other thing that could be an issue.
  • I reverted to 3.2 and then upgraded again to 3.5. While the "Try it out" button through the REST API url still does not work, invoking curl from the command-line does work.

    I think the problem is that https://<pam host>/rest_api/#/ is wrong for /rest/cmdctrl/Policy/rule/{key}. If you expand this entry, the parameter is "id", not "key". If you enter a value in "id" and then click "Try it out", the curl command URL is:

    https:///rest/cmdctrl/Policy/rule/{key}

    With some of the other commands, the parameters you enter are displayed in the curl URL. So, I believe this is a bug in the REST API web page. There are other instances where this is a problem as well. I'd recommend trying out every REST URL at https://<pam host>/rest_api/#/.

    This is all against PAM 3.5. Will be trying 3.6 soon.

  • Hmm.. I verified 'GET /rest/cmdctrl/Policy/rule/{key}' in 3.6.. For me, the parameter is key and not id, so I suspect this was fixed. Hopefully 3.6 resolve this.