Security

Hello all,

I currently have an IPAM system set up that we're using as the authoritative source for what devices should be considered as known.  I have a synchronization process from IPAM to CPPM working fairly well, but for various reasons, there are occasionally gaps where an IPAM device registration doesn't always make it into CCPM endpoints.

My current tentative plan is to configure the IPAM server as a new endpoint context server.  If I understand correctly, I should be able to configure my authentication services so that when an unknown device connects, CPPM calls out to IPAM and pulls down a list of endpoint attributes, which are then used in the rest of the AAA process.  I have the ability to create custom code in the IPAM, so I can return whatever content CPPM needs - but I can't find any docs that define what encoding and data structure CPPM expects to create my endpoint and custom attributes.

Does anyone have a reference they can point me at?

Thanks!

Hey Frank, hows things?

If your can create 'custom-code', and I'll assume we're talking EIP here, then the approach is to use the HTTP authorization source. A Content-Server/Context-Server-Action cannot return and ingest the response body from an API call to EIP {or any other system}, a CS is a PUSH only.

Use the HTTP authZ source to consume the response, easiest if you return a JSON body, then expose this into the enforcement policy..... DONE :-)

Easiest to not use nested JSON but CPPM can decode it, it just gets more complicated.

Hello all,

I currently have an IPAM system set up that we're using as the authoritative source for what devices should be considered as known.  I have a synchronization process from IPAM to CPPM working fairly well, but for various reasons, there are occasionally gaps where an IPAM device registration doesn't always make it into CCPM endpoints.

My current tentative plan is to configure the IPAM server as a new endpoint context server.  If I understand correctly, I should be able to configure my authentication services so that when an unknown device connects, CPPM calls out to IPAM and pulls down a list of endpoint attributes, which are then used in the rest of the AAA process.  I have the ability to create custom code in the IPAM, so I can return whatever content CPPM needs - but I can't find any docs that define what encoding and data structure CPPM expects to create my endpoint and custom attributes.

Does anyone have a reference they can point me at?

Thanks!

Hi Danny,

Yes, we are using EIP, and that makes a lot of sense - it certainly explains why I couldn't find what I was looking for around context servers!  I do have a couple of follow up questions:

• Will the attributes sent back be saved as endpoint attributes?
• If not, will they be referenced via the same names in my enforcement policy, or do I have to write everything to basically say "if endpoint:ipam-status OR eip-autz:ipam-status"?

Thanks!

Hey Frank, hows things?

If your can create 'custom-code', and I'll assume we're talking EIP here, then the approach is to use the HTTP authorization source. A Content-Server/Context-Server-Action cannot return and ingest the response body from an API call to EIP {or any other system}, a CS is a PUSH only.

Use the HTTP authZ source to consume the response, easiest if you return a JSON body, then expose this into the enforcement policy..... DONE :-)

Easiest to not use nested JSON but CPPM can decode it, it just gets more complicated.

Hello all,

I currently have an IPAM system set up that we're using as the authoritative source for what devices should be considered as known.  I have a synchronization process from IPAM to CPPM working fairly well, but for various reasons, there are occasionally gaps where an IPAM device registration doesn't always make it into CCPM endpoints.

My current tentative plan is to configure the IPAM server as a new endpoint context server.  If I understand correctly, I should be able to configure my authentication services so that when an unknown device connects, CPPM calls out to IPAM and pulls down a list of endpoint attributes, which are then used in the rest of the AAA process.  I have the ability to create custom code in the IPAM, so I can return whatever content CPPM needs - but I can't find any docs that define what encoding and data structure CPPM expects to create my endpoint and custom attributes.

Does anyone have a reference they can point me at?

Thanks!

So I've attached an OLD TechNote for Msoft Intune and CPPM integration, this is now out-of-date as the integration moved to a different framework around polling, where this was a real-time API driven process, exactly what you want with EIP.  The pages in the DOC hopefully make it clear how to do what you want, if not let me know.  Take a look specifically at pages 24 - 27.

Any questions let me know here, this is using an extension as a proxy to Intune, but that in terms of the config and how the data is exposed back into CPPM is mute IMO. 

Hi Danny,

Yes, we are using EIP, and that makes a lot of sense - it certainly explains why I couldn't find what I was looking for around context servers!  I do have a couple of follow up questions:

• Will the attributes sent back be saved as endpoint attributes?
• If not, will they be referenced via the same names in my enforcement policy, or do I have to write everything to basically say "if endpoint:ipam-status OR eip-autz:ipam-status"?

Thanks!

Hey Frank, hows things?

If your can create 'custom-code', and I'll assume we're talking EIP here, then the approach is to use the HTTP authorization source. A Content-Server/Context-Server-Action cannot return and ingest the response body from an API call to EIP {or any other system}, a CS is a PUSH only.

Use the HTTP authZ source to consume the response, easiest if you return a JSON body, then expose this into the enforcement policy..... DONE :-)

Easiest to not use nested JSON but CPPM can decode it, it just gets more complicated.

Hello all,

I currently have an IPAM system set up that we're using as the authoritative source for what devices should be considered as known.  I have a synchronization process from IPAM to CPPM working fairly well, but for various reasons, there are occasionally gaps where an IPAM device registration doesn't always make it into CCPM endpoints.

My current tentative plan is to configure the IPAM server as a new endpoint context server.  If I understand correctly, I should be able to configure my authentication services so that when an unknown device connects, CPPM calls out to IPAM and pulls down a list of endpoint attributes, which are then used in the rest of the AAA process.  I have the ability to create custom code in the IPAM, so I can return whatever content CPPM needs - but I can't find any docs that define what encoding and data structure CPPM expects to create my endpoint and custom attributes.

Does anyone have a reference they can point me at?

Thanks!

Time to double team Danny :)

Page 25 of the document says "Its mandated that a Login Username/Password is entered, but is not used, this it can be anything".  Are the credentials simply not required to communicate with the Intune URL as entered ... or are the credentials never used?

v6 of EfficientIP SOLIDServer has an API which requires the username and password to be base64 encoded as HTTP headers when making the request.  I assume ClearPass is not setup to handle an API such as that - though I would love you to prove me wrong.

------------------------------
Ben Higgins

Original Message:
Sent: Dec 22, 2020 05:44 PM
From: Danny Jump
Subject: Guide to creating custom endpoint context servers

So I've attached an OLD TechNote for Msoft Intune and CPPM integration, this is now out-of-date as the integration moved to a different framework around polling, where this was a real-time API driven process, exactly what you want with EIP.  The pages in the DOC hopefully make it clear how to do what you want, if not let me know.  Take a look specifically at pages 24 - 27.

Any questions let me know here, this is using an extension as a proxy to Intune, but that in terms of the config and how the data is exposed back into CPPM is mute IMO. 

Hi Danny,

Yes, we are using EIP, and that makes a lot of sense - it certainly explains why I couldn't find what I was looking for around context servers!  I do have a couple of follow up questions:

• Will the attributes sent back be saved as endpoint attributes?
• If not, will they be referenced via the same names in my enforcement policy, or do I have to write everything to basically say "if endpoint:ipam-status OR eip-autz:ipam-status"?

Thanks!

Hey Frank, hows things?

If your can create 'custom-code', and I'll assume we're talking EIP here, then the approach is to use the HTTP authorization source. A Content-Server/Context-Server-Action cannot return and ingest the response body from an API call to EIP {or any other system}, a CS is a PUSH only.

Use the HTTP authZ source to consume the response, easiest if you return a JSON body, then expose this into the enforcement policy..... DONE :-)

Easiest to not use nested JSON but CPPM can decode it, it just gets more complicated.

Hello all,

I currently have an IPAM system set up that we're using as the authoritative source for what devices should be considered as known.  I have a synchronization process from IPAM to CPPM working fairly well, but for various reasons, there are occasionally gaps where an IPAM device registration doesn't always make it into CCPM endpoints.

My current tentative plan is to configure the IPAM server as a new endpoint context server.  If I understand correctly, I should be able to configure my authentication services so that when an unknown device connects, CPPM calls out to IPAM and pulls down a list of endpoint attributes, which are then used in the rest of the AAA process.  I have the ability to create custom code in the IPAM, so I can return whatever content CPPM needs - but I can't find any docs that define what encoding and data structure CPPM expects to create my endpoint and custom attributes.

Does anyone have a reference they can point me at?

Thanks!