BYOD Solution for MAC Randomized Endpoints

[bassomarco1998]

Hello everyone,
while studying the BYOD topic, I had a doubt regarding the certificate that ISE sends to the client. Specifically, I am referring to the MAC address contained in the SAN field. From the following video (link), I saw that there is a solution that involves removing the "MAC_in_SAN" condition from the authorization policy. However, from the previous video, I cannot understand the use of the GUID. I would expect that within the authorization policy, there would be a condition where the GUID of the client's certificate is compared with another field (similar to how the "MAC_in_SAN" condition compares the SAN with the RADIUS attribute "Calling_Station_Id"). In the video, it is mentioned that this GUID is managed through context visibility. Could you explain how this GUID is used in the authorization policy?
Thanks in advance.

[Greg Gibbs]

For this particular ISE BYOD flow, the GUID is not used in AuthZ Policy. It is simply used in Context Visibility as a unique identifier for an endpoint that can present multiple different IP addresses due to the randomization.

[bassomarco1998]

Thank @Greg Gibbs for your response. Could you please tell me if it is correct to use the GUID within AuthZ policy in general? What benefits would be derived from it? How can it be implemented? If it is not recommended, could you explain the reasons?

[hslai · Accepted solution]

@bassomarco1998 No, we do not generally use GUID to base an authorization condition.

ISE BYOD has no good means to tie a GUID to a client device, unlike the 3rd-party MDM vendors who have implemented ISE MDMv3 API and they are the source of the GUIDs so that ISE may use GUID to look up the client devices and check for compliance status.