Endpoint Encryption

Hi I'm looking to deploy SEE in the not too distant future.  I've got the following set up

Win 2003 running IIS and the SEE Manager.
A 2003 SQL 2005 server
Win 2003 AD.

Currently I've got a few different msi files for the framework and full disk configurations and have just been trying out different options. We are keen to setup SEE quickly with the most minimal impact on staff but as we have various laptops will probably go for the manual install method to insure nothing breaks (and if it does then at least its controlled).  So AD doesn't really need to be involved at this stage, although we may use it to deploy changes to settings in the future.

To avoid staff requiring two passwords, there will be just the windows login and the user has to register with a password to access encryption (as we will be sitting next to them when they register).  We wont be making use of one time passwords or authenti check as login will be tied to the windows login.

I was just wondering if anyone has a similar setup and if they had come across any pro/cons to this configuration and if this config raises any security concerns or issues?

Any thoughts you have would be interesting to hear.

thanks

Sam

HI Sam,

We did the manual install method first time off too, it lets you sleep better! I'm a little confused by your plan to only use Windows passwords but require a password for SEE access - how are you planning to do this? I *think* that if you require a password to authenticate to SEE it automatically means you have to use the pre-boot authentication, though I could be wrong.

As you've worked out already the advantage of this method is little user impact but it's worth considering doing it the other way round and using single-sign on. This means the user gets the SEE pre-boot authentication prompt but doesnt have to enter the windows password later on, so still one password but just at the very start of boot instead. This password is synchronised with AD. The disadvantage of relying on the Windows logon is that officially windows is up and running and can be "accessed" on the network or potentially other 3rd party tools that might be able to gain access to the system, whereas with the pre boot option, the first use of the disk is protected by a strong encryption. Of course the disk is still encrypted if removed from the machine so its already more secure.

I guess what it comes down to is how secure you need to be and what you're protecting and where you are prepared to place the balance between security and flexibility...

Hope that helps, I'm sure the other guys on the forum will have some other opinions worth having a think about :-)

A couple things to consider:

- If you manually deploy, you wouldn't be able to deploy settings changes via AD, you would need to use Native Policies in the SEE Manager Console.

- The Single Sign-On feature allows users to authenticate to both SEE and Windows at the same time allowing them to access the User Client Console without an additional logon. This installation setting can be changed later using a policy.

- Authenti-Check allows users without credentials to gain access to their computers and/or the User Client Console without assistance.  Useful in those situations where a remote user does not have access to the domain, or the help desk for One-Time Password assistance.

- One-Time Password (OTP) enables you to assist users who can’t get into Windows because they forgot their credentials or have been locked out for a failure to communicate with the SEE Management Server.  I would recommend having this feature enabled as it would be to your advantaged to assist remote users, should the need to unlock a machine on the road arise.

Reference the SEE Installation guide on configuring these options.  Make sure you've thoroughly mapped scenarios where these may be needed before choosing not to deploy them.

Hey Sam,

I agree with David/Tbone. if you are disabling an option then lookout for the disadvantages like Tbone mentioned about Authenti check quetions. This is a good feature and I personally feel you should enable this.

If you want to strip down the installation and go with what you want -- this can be done -- I mean no SEE authentication window and only windows authentication comes up directly. If this is manadate and the other options as you mentioned -- then this is the way it has to be done.

I understand for the first time end users need to fill some fields but trust me it helps in long run. If there is something you are looking for or (god forbid) if things are not falling in place for you then feel free to put up your question. Now we have Symantec tech support in this forum too -- right Tbone ;-)

Thanks for your responses guys - very usefull indeed.  I been working through the various scenarios and am glad I'm not off target from what has been meantioned.  Once thing I have noticed though is related to Tbones comment that manually deploying results in changes not being availble via AD.  Settings changes do appear to be applied i.e. I made a change to the SEE login display banner which has updated after running GPupdate /force - should this not be the case then??

With regards to my windows only login comment, I was planning to ensure that the user has to enter a password to be allowed to register a client account on the computer .  I see this as ensureing we control who can register on the device.

Thanks again,

Sam

With what Tbones said -- I agree/disagree to it ..... Means we earlier had some issue with when packages were installed manually and then you tries upgrading it via gpo to a newer version however Sam as you mentioned GPO settings change should work well .... I need to check when 706 or whichever next version comes out -- how it'll behave ...

I'm not sure how GPO policy changes could be working if SEE wasn't deployed via GPO.  This should be the case with any software, not just SEE.  I'm assuming you added a software deployment GPO after manually installing SEE, and you're attempting policy changes in this GPO?

I disagree! GPO changes to policies or settings in software can definately be done if the software wasn't deployed with GPO. Unless you're only refering to the upgrade, in which case this is true for SEE but again lots of other software can upgrade via GPO.

Yep, my mistake, thinking off topic.  Researching internally for verification of SEE's ability to be changed via GPO for a non-GPO deploy...

HI All,

Verified internally that GPO application of policy changes should not be able to change policy in manual installed SEE clients.  Not disputing what you're seeing, just passing along information.  Will need to set up internal testing to verify the behavior seen...

Tbone - I haven't fully deployed yet, but have manually installed some clients through Altiris.  Yet I'm trying to decrypt some now through GPO and am not having success.  You saying it's because I didn't install the clients via GPO?

Yes, that's correct.  Why policy changes appear to be happening under this set of circumstances is something we need to test.  The behavior you're seeing with trying to decrypt via GPO for a non-GPO deployed client is the expected result.

To those who are seeing GPO policy/settings changes take place in non-GPO deployed clients, in the SEE Manager, are you seeing your client machines listed under Symantec Endpoint Encryption Managed Computers in the AD portion, or Symantec Endpoint Encryption Managed Compuiters?

I was being a retard and got mixed up to which computer was in my test OU.  I have confirmed my test desktop to be decrypted via the GPO setting I applied and this client was manually installed (via Altiris).

I'm seeing my clients in the AD side of SEE Managed Computers.

Keep in mind, I'm a real newbie with SEE, but isn't it that computers under the non-AD side of SEE Managed Computers are non-domain computers?  That'd be why GPOs wouldn't work as they wouldn't see these workgroup computers.

hummm ok well thats a bit confusing.  From what I remember I had installed SEE on clients by manually running the msi file on the device.  Then I made some changes in the GPO settings  within SEE management i.e. add in a new administrator account and then on the device from the command line typed in gpupdate /force and after rebooting the new admin account was available to use.  I can go back through my testing to see if i've got this wrong but are you saying this shouldn't be possible?  

With regards to the authentication options and preboot, thats a good point ukDavidC about SEE running before Windows is on the netwowrk.  This could catch me out with those who need remote access to their PC's though as if the PC is rebooted then they won't be able to login to SEE.  I might have to have a couple of configs to deal with these types of needs.

I let you know what eles i find.

thanks

Sam

There is the concept of AutoLogon that could help you with the remote access - I beleive it's designed for this purpose, allowing you to do maintenance and reboot without authentication for x number of times.

Can I ask about these GPO's please/

I have deployed manually, but can't get my head around, why mahines settings for SEE (custom AD) cannot be configured on a GPO!?

Does the SEE atributres not get copied to sysvol\info ddorectory on the DC's or something?  I have all roles installed ont h single server using a domain admin account on SEE 11.05.

CAN ANYONE tell me whether manual install = native policies only?

If I want to use AD, do I need to deploy via AD?

As far as I know most of them can. I'm running an environment where all the clients were manually deployed (and by definition have 'native' policies but only in that they're configured in the MSI packages themselves) and then have changed the settings using AD group policy. Are there particular settings you want to check?

David,

cool

That was what I was thinkging:

We have the settings in the package as well, and they are not subject to chage much - but there will be the odd, need to decrpyt drives to rebuild PC for example - I CANT see what I couldn;t use the GPO to do this.

In terms of organisation, do you use the native polciy node or AD groups and computers i.e put them into a certain OU - I was going to keep current AD structure and delgate GPO to a global group instead - guess many ways to do it - company has said they would like AD admin where psosible - just trying to uderstand how it all hangs.

Sorry for taking a while, didnt notice this one. We use AD and set the GPO policies at OU level. Our AD sctructure lends itself to this as most of the machines we want to encrypt are in the same OU (or lower). You can then delegate as required. 

Alternatively if you dont want to bother with the delegation to admin staff you could just provide an see local user account and the access CD's. This lets them override the encryption and do rebuilds, repairs or whatever is required. You can also build a custom version of the access CD and add any other tools you need, e.g. Ghost for imaging etc. Depends on the size of your systems of course.

Thanks - i read about the CDs in the guide - used to recover the system in the event of  aproblem right?

Do you create them from the managment console or the clients themselve?

Thanks again.

There are two - one for access and one for recovery. The first gets to access to a disk, its the equivalent of the pre-boot environment. The other is recovery that allows fixing of the PBE etc. Both require authentication. They should be in the installation packages / CDs in ISO format. You usually also get a 'utilities' folder that explains how to make a custom one.

Hope that helps

Thank David - I am planning on using 2 different client admin accounts - one very limited, but will get helpdesk through and one used to uninstall client..etc.

LAST THING (sorry!!) - with th amount of accounts you can create and use - did you think yourself using only a few domain accounts for the various roles?

e.g. one for db communication between manager and db, one for AD sync, one for IIS, one for policy admins- gets a little silly!!

We are putting all roles on one VM - think may have  a main locked down 'service account' for see - wuill see how compnay want it froma a security point of view.

Totally depends on your normal procedures for service accounts etc - this isnt really specific to SEE but usage in general.....