In DAG environments, a shadow server in remote Active Directory site is preferred.

That is interesting, reading more from

http://technet.microsoft.com/en-us/library/dd351027(v=exchg.150).aspx

If the primary server is a member of a DAG, the primary server connects to a different Mailbox server in the same DAG. If the DAG spans multiple Active Directory sites, a Mailbox server in a different Active Directory site is preferred by default.

This means that servers in DAG will copy the message to a remote AD site by default, that might be ok for you, but for some environment this might not be the case due to network constrains.

to control this setting, continue reading:

This setting is controlled by the ShadowMessagePreference parameter on the Set-TransportService cmdlet. The default value is PreferRemote, but you can change it to RemoteOnly or LocalOnly.

so you can use the set-transportservice cmdlet to control this setting.

Just a reminder to all of us.

Understanding Email Policies:

Email policies are the foundation block for handling email, they determine how emails from specific senders sent to specific recipients with specific contents will be handled.

There are set of defaults policies created by default:

they determine how outbound/inbound emails will be handled, the default policy has the following settings:

the outbound client has the following settings:

which tell the SES to encrypt the emails if the source client is SMTP/MAPI to send it to the outbound chain which does the encryption actions:

if we explore the outbound chain, we will find the following settings:

which instructs the SES how to handle specific emails with specific conditions, so I edited this rule and added the “confidential rule”, which encrypts emails sent internally or externally with the word “confidential” in the subject line. You can add your own set of rules to meet your business and enforce certail delivery types link web or protected PDF:

Once you set the rules, you can send encrypted emails, let us see how:

from outlook client, I will send normal email to user@domain.com (which is fictional domain), the client will detect the policy that is set on the server and will send the email out of message steam to the SES:

Because we can’t find a key for user@domain.com, we will send the email to the SES server and the SES will send the user an email notifying him that there is a message waiting him:

In the above email, I am opening the EML file via notepad (I do have only SMTP server at the recipient side), so the message contains the link to open the email (take a look to how the email flowed from the client to keys “the SES Server” to Exchange to the recipient server)

when opening the link, the client will be prompted with the registration (to register in the SES portal with a passphrase), Then the user can login:

Once user login, he can see the email through the portal; The user can reply and interact securely with the internal user or ask for email delivery via secure PDF:

We reached the end of this series, we can send and exchange emails securely with Symantec Encryption Server now. I hope that you liked this series.

Thanks everyone, I promise you to deliver and give more.

In This post, we will explore a very important aspect in any encryption solution, which is key management.

Introduction:

to understand what is public/private keys, check these link:

http://www.comodo.com/resources/small-business/digital-certificates2.php

http://blogs.msdn.com/b/plankytronixx/archive/2010/10/23/crypto-primer-understanding-encryption-public-private-key-signatures-and-certificates.aspx

If you read the above articles you will now realize that we will use public and private keys; While Microsoft uses x.509 certificate based on Microsoft CA which utilizes s/MIME to encrypt the messages, Symantec Encryption server uses PGP keys which uses different structure, keys are stored in PGP LDAP server (we will see how to import x.509 certificate to Symantec encryption server later).

Keys Provisioning:

In order for a user to obtain PGP keys, the user must register for PGP keys with the server, let use see the steps to do that.

To Configure email enrolment, first you need to define email route, this tells the encryption server where to send the registration emails and any emails send to your domain, from the control panel, go to mail > mail route and add email route to your server

When you download the Desktop encryption install package and install it on the machine, the client will detect automatically the encryption server and try to contact the server, since I don’t have a valid certificate on my server it will warn me; Click on always trust this site.

enter the email address:

the user will receive an encrypted email

once the user opens the encrypted email he/she can continue the registration:

verify the username and email address:

create a passphrase to protect your key (remember this step as we will talk about it later in details when speaking about the key storage types):

the key will be generated for the user:

now when you open the Encryption Desktop, you will see the keys and policies created by the encryption server assigned to the user:

in the console, you can see the list of managed keys as well:

If you click on the key mode button (from the Desktop Encryption window), you will see that the key is operating ins SKM mode; so what is that?!

Keys in Symantec Encryption Server operates in different modes, the modes are:

• Server Key mode: In this mode, the private keys are stored on the server and users can’t manager their keys
• Client Key Mode: In this mode, the private keys are not stored on the servers and users must manage their own private key and protect it.
• Guarded Key Mode: In this mode, a pass phrased protected private key is stored on the server and clients manage their key
• Server Client Key Mode: a sub key of the private key is stored on the server, the private key still stored on the client.

you must be very careful when selecting the key mode in your environment; depending on the key mode, you will have or lose some features as per the below table:

for the first instance, SKM might be the ultimate answer, but you have to be aware that administrators have control over private keys, so this might be a security concern.

To change the mode of the key being used, click on the reset key button and you will be taken through a page that will help you selecting the appropriate key mode.

you can also restrict the modes available in your organization, to do so, edit the consumer policy and change the available modes:

The Symantec Encryption Server binaries are certified to be installed as virtual and this is the recommended use from Symantec, and this is the method we will use in our environment.

Symantec Encryption Server can manage several different encryption products and solutions including:

• Symantec encryption email gateway.
• Symantec Encryption Desktop.
• Symantec File share encryption.
• Symantec Encryption portable.
• Symantec Drive encryption.

In this blog, we will install the Symantec Encryption Server v3.3, the latest version (at this time) of the product. There are several design and architectural decision elements that must be taken into consideration for several features to work; we will explore them later.

To install Symantec Encryption Server, download the ISO image and create a virtual machine, the documentation and install guide mandate that the VM must be created with Kernel 2.6 x86, 4 GB memory for single instance and 8 GB for HA instances.

Once you start the VM with the ISO attached, follow the simple install wizard that will take you through the installation steps:

In the IP address field, specify the IP address for the appliance:

Specify the Gateway and DNS servers:

Specify the host name; one important point is to note that your appliance MUST be named (keys.domain.com), this is mandatory if you want to cooperate with other PGP key servers. PGP keys servers contacts the recipients keys servers “if available” (if the server can’t locate a public key for the recipients) on keys.domain.com, thus if you want to facilitate exchange secure emails with external parties you must name the server’s FQDN keys.domain.com and this name must be reachable from outside.

Once you finish the wizard, the setup will start automatically, once finished the appliance will reboot and the post complete setup will be launched:

accept the license agreement

from the installation type, choose the installation mode. since this is the first server we will choose new installation.

set the time/date:

Confirm the IP settings:

Confirm the setup summary:

Reboot:

Enter the license information:

Enter the administrator information and password:

enter the primary domain that you use to send/receive emails:

To protect the server in case it is physcially attacked you must configure the ignition keys, I will use a passphrase as my ignition keys; enter them and continue:

review the setup summary:

Once setup completes you can login to the admin console on https://keys.domain.com:9000

This completes the Symantec Encryption Server installation, in Part 2 we will continue with the initial setup and keys management, part 2 and 3 will be fun, so stay tuned .

The reason of what brought DLP to the surface is that I had a discussion with one of my customers on DLP enforcement and how to manage it within his infrastructure. While reviewing Email encryption solutions by Sophos and Symantec last week; I found that each vendor has his own concept “if we may call it like that” on DLP and how to manage and enforce it.

First, let me state my own view of DLP; DLP is a technology that helps the organization to own the information/data and prevent leaking those information/data out.

Modern information/data is stored in different locations now, some examples:

- ERP/CRM data.

- Email, Office files, PDF documents.

- SharePoint and similar portals.

- Laptops, USB memory sticks, and portable hard disks.

Helping any organization to control data on the above sources is not easy and could be done in several manners and ways, based on my findings; I will share some thoughts with people thinking about rolling out DLP in their infrastructure:

- DLP is not controlling physical ports (USB, serial, firewire ports..Etc).

- DLP is not DRM nor Encryption.

- Permissions help in controlling the data access, but when the data is accessed; a malicious consumer of the data could share them with 3^rd parties or leak them out either intentionally or unintentionally.

- Internal users do most of the hacks/leaks.

- Encrypting the data might help in DLP, but will not help in controlling what happens if a malicious user decrypted them or encryption algorithm is broken, Also encrypting the data might not help when the organization need to share All/some data with authorized 3^rd party.

- If the IT department secured physical ports/access, what about leaking the data out using corporate emails or worst, personal emails.

- How you will classify data as corporate and how you will classify data as none-corporate.

- Data classification is suitable for data stored in shared folders, but what about data in SQL/Oracle databases or data copied from documents and sent as emails.

- How data will be shared with 3^rd party and secured outside the organization’s control circle.

- Monitoring, logging and alerting, and feeding other 3^rd party security applications that are used by the security team.

- What about endusers experience, do we need any input from users?

- What about data in the cloud?!

As you can read from the above, DLP will never be a single solution/technology, DLP is a mix of solutions, technologies and processes that govern the data inside the corporate.

Hope that the above thoughts will shed some light and ring some bells in your head when thinking about DLP.

To help you addressing this challenge and spotting those points, we will release a white paper that identifies key elements to consider when backing up and recovering virtual machines and explains them in details.

So stuff like Agent or agentless backup, unified or virtual specific backups, Data Deduplication (how, when) with virtual machines, large backup sets, granular vs. one backup/restore set, adding to that great and critical tips for applications (AD, SQL and Exchange), Hypervisors (VMware/Hyper-v) and network layer.

This unique white paper has been written by a group of the best minds in applications, virtualization and backup worlds, the authors of this white paper are:

• Thomas Maurer: Thomas is Hyper-v MVP, well known in his contributions in System Center, Hyper-v and cloud community.
• Mikko Nykyri: VMware vExpert and virtualization product mangaer for backup exec.
• me, Mahmoud Magdy

In this white paper; Published at Symantec here http://ow.ly/kOQBJ , we bring you the top points to consider, key factors and top issues to identify when backing up and restoring virtual machines, we will also go through a Google hangout session discussing those elements in details.

so start tuned, and follow us on Twitter, Linkedin and facebook and wish you all happy backup and successful restore.

In this blog series, I will list recommended reading for several technologies and components and how you can build knowledge around that, of course; hand-on and time will give you the required experience, but these recommendations will help you to stop the no-clues auto-pilot mode.

I will start with AD, please note the following:

• You might have different opinions about the readings, again these are my recommendations.
• I read the below list so when I complied this list I wanted to cut it short for you instead of reading useless stuff.
• You will still need to build hands-on experience.

so let us start with the Active Directory reading lists:

This list will be updated on regular basis to reflect the most recent interesting reads, I wish you all successful career in AD.

What a great news, can’t for service pack 1….