cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1397
Views
0
Helpful
5
Replies

ISE 2.1 Internal User Rest API filter calls

trcolber
Cisco Employee
Cisco Employee

Need assistance on REST API calls with internal users via Google Postman using filters. They do not seem to work as expected with certain filters. Trying to filter on field ‘passwordIDStore’ in order to determine if cx is using internal, AD or any other ID store but we are not able to get this to work. Also trying to filter on ‘expiryDateEnabled’ and the ‘enabled’ field option as well for internal users, but having no luck here. The screenshot below shows all supported filters for internal users but having issues with these specific ones. Any assistance you can provide with the proper API calls to use for these filters would be appreciated since they seem to return all internal users with every query.Screen Shot 2017-08-06 at 10.49.27 PM.png

1 Accepted Solution

Accepted Solutions

hslai
Cisco Employee
Cisco Employee

I, too, am having troubles with some of the supported filter, including passwordIDStore. I would suggest to go ahead and log a bug. Meanwhile, I will check with our development.

I tested with ISE 2.3 and

Filter: [expiryDate, firstName, lastName, passwordIDStore, identityGroup, name, description, email, enabled, expiryDateEnabled]

expiryDate EQ —> java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Long

expiryDate GT/LT —> all

passwordIDStore EQ/STARTSW/ENDSW/CONTAINS —> 0 returned

enabled —> all users regardless enabled/disabled

expiryDateEnabled —> java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean

View solution in original post

5 Replies 5

Craig Hyps
Level 10
Level 10

Recommend review the online ERS SDK for examples of using filters.  If still not working, try posting example of your query.

I am not seeing the passwordIDStore available when you do a general Internal User query.  (i.e. Get All)  I only have one internal user configured whose password store is set to AD.  When I query all Users I get:


https://restadmin:Temp1234@10.89.80.34:9060/ers/config/internaluser


{

    "SearchResult": {

        "total": 1,

        "resources": [

            {

                "id": "d459bd6b-a4d3-42b6-b2ca-d55f5edcb837",

                "name": "phaferman",

                "description": "",

                "link": {

                    "rel": "self",

                    "href": "https://10.89.80.34:9060/ers/config/internaluser/d459bd6b-a4d3-42b6-b2ca-d55f5edcb837",

                    "type": "application/xml"

                }

            }

        ]

    }

}

If I then query by it's ID I can see the password store:


https://restadmin:Temp1234@10.89.80.34:9060/ers/config/internaluser/d459bd6b-a4d3-42b6-b2ca-d55f5edcb837


{

    "InternalUser": {

        "id": "d459bd6b-a4d3-42b6-b2ca-d55f5edcb837",

        "name": "phaferman",

        "enabled": true,

        "password": "*******",

        "changePassword": false,

        "identityGroups": "cc548910-7203-11e7-8a6f-0050568886cf",

        "expiryDateEnabled": false,

        "enablePassword": "*******",

        "customAttributes": {},

        "passwordIDStore": "CSATENG_AD",

        "link": {

            "rel": "self",

            "href": "https://10.89.80.34:9060/ers/config/internaluser/d459bd6b-a4d3-42b6-b2ca-d55f5edcb837",

            "type": "application/xml"

        }

    }

}

I can filter query by name just fine:

https://restadmin:Temp1234@10.89.80.34:9060/ers/config/internaluser?filter=name.EQ.phaferman

{

    "SearchResult": {

        "total": 1,

        "resources": [

            {

                "id": "d459bd6b-a4d3-42b6-b2ca-d55f5edcb837",

                "name": "phaferman",

                "description": "",

                "link": {

                    "rel": "self",

                    "href": "https://10.89.80.34:9060/ers/config/internaluser/d459bd6b-a4d3-42b6-b2ca-d55f5edcb837",

                    "type": "application/xml"

                }

            }

        ]

    }

}

But I cant query by password ID store:

https://restadmin:Temp1234@10.89.80.34:9060/ers/config/internaluser?filter=passwordIDStore.EQ.CSATENG_AD

{

    "SearchResult": {

        "total": 0,

        "resources": []

    }

}

As I showed passwordIDStore is not available in the Get All results so I don't see how you can filter on that value.

My 2 cents.

hslai
Cisco Employee
Cisco Employee

GetAll returns only a smaller set of attributes and may not include those available as filters. For example, I am able to filter on firstname

GET https://myISE:9060/ers/config/internaluser?filter=firstName.EQ.Cert

Accept: application/json

-- response --

200 OK

Cache-Control:  no-cache, no-store, must-revalidate

Expires:  Thu, 01 Jan 1970 00:00:00 GMT

Pragma:  no-cache

Date:  Tue, 08 Aug 2017 00:39:52 GMT

Content-Type:  application/json;charset=utf-8

Content-Length:  370

Server: 

{

  "SearchResult" : {

    "total" : 1,

    "resources" : [ {

      "id" : "a3d85fa6-8e77-4c7b-9bd2-19d4fac61b49",

      "name" : "cert",

      "description" : "",

      "link" : {

        "rel" : "self",

        "href" : "https://myISE:9060/ers/config/internaluser/a3d85fa6-8e77-4c7b-9bd2-19d4fac61b49",

        "type" : "application/xml"

      }

    } ]

  }

}

hslai
Cisco Employee
Cisco Employee

I, too, am having troubles with some of the supported filter, including passwordIDStore. I would suggest to go ahead and log a bug. Meanwhile, I will check with our development.

I tested with ISE 2.3 and

Filter: [expiryDate, firstName, lastName, passwordIDStore, identityGroup, name, description, email, enabled, expiryDateEnabled]

expiryDate EQ —> java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Long

expiryDate GT/LT —> all

passwordIDStore EQ/STARTSW/ENDSW/CONTAINS —> 0 returned

enabled —> all users regardless enabled/disabled

expiryDateEnabled —> java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean

Thanks for the response Hsing and glad you are able to reproduce the issue as well. I will file a bug for this.