we are migrating from v 126.96.36.199 to v6.1, still testing it.
I have run eemigration tool on our 'safeboot' box, generating a zip file. I then run the import v5 users successfully into epo (4.5.4HF1).
My question is:
We used to have users assigned to a 'safeboot_users' group, but it seems now that when I create a new account in AD and the EE LDAP task runs the new user account gets sync'ed with epo and this new user can then log in with 12345 PBA, then to Windows. After policy enforcement is completed a reboot and user can use his password to get past PBA and Windows via SSO.
I have already setup a group on Menu----Data Protection----Encryption users----Actions----Endpoint Encryption----Add User. Therefore I thought that only members of this group would be able to log in top encrypted laptops
How can I setup just a specific group of users to be able to login to encrypted laptops???
I am definitely missing something, sorry for the dumb Q
Comments are appreciated
The method you are using will result in the selected user or user group being assigned to one system. If you want to assign a user or group to all encrypted systems, then you need to use the Group Users screen. Go to menu>data protection>endpoint encryption users>group users. Any user or group you select here, will be assigned to all systems in that part of the system tree. If you want those users to have access to all systems, simply do this at the My Organization level of the tree (the root).
Are you saying that instead of asking users to login to a system so they get "cached", I can do everything from within a group? Would this group be "pushed" to all laptops with EEPC6.1? Another problem is that from research it seems that 6.1 has a limitation of recommended 350users with max of 500 users per device. At the moment we have 731 users on v 188.8.131.52 and this would be an issue with 6.1
Comments are appreciated
The limit on users is defined by the Preboot Filesystem size, which defaults to 20MB but is confirgurable in EEAdmin. Also, if you are a password-only customer (i.e. you don't use smartcards) it would be worth changing your LDAP sync task to remove the "certificate" field so that user's certs are not synced across.....these certs take up quite a lot of space and if you are password only you don't need them.
Where do you see it stated that the product can handle a max of 500 users per device?
dwebb, thanks for your prompt reply
I attended a McAfee webinar this week (lost the first 45min). Will attend another on Monday 13 Jun
How many users can be accommodated by the default PBFS size?
Approximately 350 users. (speaker menitoned that 500 could be squeezed in)
How much space will a single user occupy in the PBFS?
Approximately 8-10 KB.
Can I change the default size of the PBFS?
Yes. This is a Server policy setting.
What is included in the PBFS?
The PBFS contains all of the necessary information to provide the user with the ability to authenticate. This includes but is not limited to:
- The files necessary for the Pre-Boot Environment
- Language files for all supported client languages
- Fonts to display characters from all supported languages
- The theme assigned to the client
- The users assigned to the client
Ok, so what the speaker probably meant was that 500 could be squeezed into the default PBFS size.
I would recommend that you up the PBFS size to 30MB, remove the certificate sync from the sync task and then test with your 700 users. It should be fine (note that if you see sluggish behaviour at login, it will be because a lot of syncing of the 700 users is occuring which locks the PBFS preventing the login from hapenning. Login and then retry login an hour or so later and the problem should have gone once the users have all synced across.
dwebb, thanks again.....
when you saying sluggish behaviour at login, do you mean the whole boot process or just from CTRL+ALT+DEL screen?
Slightly diverting from original post, I am curious about sluggishness because I have been trying to troubleshoot a slow login problem on our network and have not thought about safeboot. Came across this thread: https://community.mcafee.com/thread/32300 post #4 "....BUT it won't let a third party GINA start until all drivers are done, because there may be some dependencies, etc..." (We use Novell). Have been using Xperf to diagnose it.
It maybe a good ideia, as we are migrating, to just have users sync'ed via "add local domain users" rather the bloating a group.
Hope someone can come up with some comments/suggestions
Just from Ctrlaltdel screen......the system will activate after the first batch of users is received, so when it gets back to login prompt it may be syncing further users down to preboot, meaning that the credential provider is blocked from accessing the PBFS temporarily, meaning that login can appear to take a little while. Once all users are synced, the sluggishness disappears.
More generally, we have seen certain third party services fail to start properly, preventing the EEPC service from starting up until Windows times out the offending third party service. This can result in a delay at login. Windows will timeout the service after around 80 seocnds, so if you are seeing such a delay it could be that a service (not EEPC) is failing to start properly, meaning that all subsequent services are blocked from starting. Check this out in the system logs and look for errors starting services.
Yes. You don't have to ask users to login to Windows once and get cached. That would only be a requirement if you were relying purely on our "add local domain users" feature. This is one of three ways to assign users to systems.
Most customers will use a combination of option 1 and 3. They use 1 to assign end users to systems, and they'll use 3 to assign administrative or support users to systems.
The only tricky use case is the case of brand new systems. Since they don't have any cached users, it is difficult to use option 1. But for that, we recommend simply using two policies and switching them after the system gets some cached users. You can see the process here: https://community.mcafee.com/blogs/danlarson/2009/11/25/eepc-v6-best-practice-temporarily-enable-aut...
You can fit 731 users in the pre-boot environment, no problem. But there is a right way and a wrong way to do it.
As dwebb says...
The reason that support and some others in McAfee recommend assigning smaller numbers of users to systems is for scalability. If a customer with 100,000 laptops assigned 5,000 users to every system, their ePO server would probably start smoking. It is just a lot of calculations to process lots of users on lots of systems all day long. ePO can do it, but it will suck a lot of resources. Since you are only talking about 731 users, I'd bet that you have less than 1,000 systems. So assigning 700+ users in that environment is not a problem - as long as you follow the advice above.
For your use case, you should just go in the encryption users screen and leverage the Group Users features. Pull your AD group that has your 731 users and assign it to the My Organization level of the system tree. Then I'd disable the add local domain users option in the system settings policy since you no longer need it.