FRP without Grantkeys on a new epo Server

[Davide1]

We still used FRP with grantkey assignment until today, so the encryption works fine.

Now we want to migrate to the latest ePo server and the grantkey assignment is no longer supportet. I have now tested the newly created FRP keys (without Grantkey) with a customer. When assigning to his device, the encryption and decryption works, but when I assign the FRP key to an Active Directory user or group, the key does not arrive.

It doesn't matter if I enable OS Authentication or Password Authentication, the FRP key just doesn't arrive when assigned to a user or group.

Does anyone have a hint what the problem could be?

Thanks a lot in advance.

[aguevara]

lets move this to the FRP group for proper visibility

[JaganA]

@Davide1 Thanks for choosing community forum.

Kindly validate the steps as available in the following article:KB89688

Also, ensure to run the task. The issue may occur if the user details were not fetched successfully from LDAP. In that, looking into the ePO orion.log would help further.

[Davide1]

@JaganA:

Thanks a lot for your assistance.

The problem may have effectively been the FRP tasks and LDAP-Sync task, both tasks was set to 24 hours and of course i mostly checked after a few hours.

I will do the assignment again and if necessary check the orion.log and report here again if it worked.

Thanks for the support.

[Davide1]

Hello @JaganA ,

I have made multiple tests on the epo Server and on the client and the FRP assign task to the AD user or AD group successfully completed. 

I have noticed that the user also receives the key as soon as he manually selects Quick Settings on the McAfee icon and then Logon in FRP and authenticates himself with the AD user name and AD password.

Is there a setting to enforce this FRP-login procedure in a FRP policy? I have not found any options.

Thanks for you appreciate help.

[cross · Accepted solution]

When keys are assigned in the current versions to a user, there is a need for an unlock trigger to occur in order for the key(s) to be made available.  This is only applicable to keys assigned to users\groups\OUs but not system assigned keys.  There are three unlock trigger choices that can be selected in policy which include the "McAfee tray" which is the one you have noted above.  The other two options that you are inquiring about are in the FRP "Authentication (User-Based Policy)" in the "Encryption Key Options" tab in the top section called "Unlock Triggers". In addition to the tray choice, there is "Windows Logon" and "encryption key access" which can be selected as well.

I should note that policies with either (or both) of these additional unlock triggers enabled should typically only be applied to systems and/or users that have user-assigned keys. Having it set to trigger an unlock of a user-based key without a user-based assignment with either of these two additional options will trigger a logon prompt and then a subsequent failure to logon for FRP if the user does not have any keys assigned.

[Davide1]

Thanks @cross, i will try the unlock trigger option. 

But i am confident that this is the solution to go.

Thanks for your appreciate support.

[Davide1]

Hello @cross, the unlock trigger option was the way to go. The assignement of FRP-Keys works great.

I have only still one problem. On some keys, where i assign two or more Active Directory Groups, i see the message: pending processing

In Server Task log i see the follow message:

Failed to process assignment of Key GUID: 4E505150-587D-4921-A571-3C59010CCE55 to Directory ID: AE7719C905927D4AAD462CE8E1F3D533, for authentication type: OS

Do you know where is the problem on these FRP Keys?

Thanks for your support.

[cross]

That situation could be a few possible items.  We'd probably need to see what is shown for that task during that time in the Orion log to start with and then depending upon what that shows there may be a need for a few possible SQL queries.  I'd suggest opening an SR for that.

[Davide1]

@cross:

I have noticed that the Active Directory groups specified under FRP Assign are empty, where the pending process gets stuck. So actually no problem at all.

Thanks for the quick answer. Really great help here