Professional Documents
Culture Documents
Exchange, ADFS, O365
Exchange, ADFS, O365
A hybrid deployment provides the seamless look and feel of a single Exchange
organization between an on-premises Exchange organization and Exchange Online
in Microsoft Office 365. A hybrid deployment offers organizations the ability to extend the
feature-rich experience and administrative control they have with their existing on-premises
Microsoft Exchange organization to the cloud.
ADFS Server
Server that links to the credentials, and has the claims configuration as well as the
trusts. Generally not publicly accessible.
ADFS Proxy Server
Server that hosts the IIS instance that has the login pages for the websites requiring
authentication. Communicates back to the ADFS when requiring authentication.
Generally publicly accessible.
Single server installation option removed and now have single farm install
(recommended to install a farm always in prior release anyway)
Separate ADFS proxy role removed. ADFS proxy now based off Web Application
Proxy (WAP), and is used to publish the ADFS server to the Internet. WAP can
publish many other applications, not just ADFS.
ADFS extranet lockout ADDS account lockout protection on the ADFS proxy
The wizard also states that you must have access to Domain Admin (DA) credentials!
Note that you are only given an option to either make a new ADFS farm or add this box
to an existing farm. This saves the painful issue from older ADFS builds, where ADFS
was not installed into a farm you were then unable to easily the add the second ADFS
server for redundancy.
Provide your domain admin credentials.
We need to select the SSL certificate that we will use and also provide the ADFS name
we selected in the design process.
#
# Windows PowerShell script for AD FS Deployment
#
Import-Module ADFS
Install-AdfsFarm `
-CertificateThumbprint:"5804746A7980C8682FBF408D48EF6C3B02A5ZORG"
`
-FederationServiceDisplayName:"Tailspintoys STS" `
-FederationServiceName:"adfs.Tailspintoys.ca" `
-ServiceAccountCredential:$serviceAccountCredential
The ADFS pre-requisite checks are done, and we can proceed to the configuration:
The ADFS -- Active Directory Federation Server -- doesn't not hold that database, but serves
as an intermediary from another/different external domain (or similar) then queries a
Domain Controller to request authentication for users trying to access that external domain.
An example would be a Office 365 deployment in the Microsoft Cloud (that is on the
Internet) might request the ADFS server to authenticate each user on the internal domain.
ADFS would pass this request to a domain controller and the answer back to the Office 365.
What is Directory Synchronization?
Directory Synchronization is the integration of your On-premises Active Directory
with an instance of Active Directory running in the Azure cloud. Synchronization
essentially makes a copy of the on-premises directory objects and then propagates
them to an Active Directory instance in the Azure cloud. After that, synchronization
runs on a scheduled basis to push changes from the on-premises directory to the
cloud instance. With few exceptions, synchronization only goes from on-premises to
the cloud. If one were to create a new user on the Azure Active Directory tenant,
that user would live only in the cloud and would never be propagated down to the
on-premises directory. This would create a Cloud (only) Identity (see below) which
would have its own login credentials and identity for Office 365 applications.
What is Federation?
Active Directory Federation Services (AD FS) can be used to provide
federation and single sign-on capabilities for end users who want to access
Office 365 applications. Windows Server 2012 R2 includes an AD FS role that
can function as an identity provider or as a federation provider. An identity
provider authenticates users to provide security tokens to applications that
trust AD FS (e.g. Office 365 applications). A federation provider consumes
tokens from other identity providers and then provides security tokens to
applications that trust AD FS.
Windows Server 2008 and Windows Server 2008 SP2 are the same operating system, just at a
different service pack level (Windows Server 2008 started at the SP1 level because it was released
quite a bit after Windows Vista and SP1 ).
Windows Server 2008 R2 is the server release of Windows 7, so it's version 6.1 of the O.S.; it
introduces quite a lot of new features, because it's actually a new release of the system.
Windows Server 2008 R2 is includes key enhancements related to virtualization, management, IIS,
scalability and reliability, and Windows 7 integration
There are also differences at the GUI level, because WS2008R2 uses the same new GUI introduced
with Windows 7 (new taskbar, etc.).
Depending on what kind of applications you're developing, they may or may not encounter
problems on different O.S. releases; you should definitely check MSDN.
**Windows Server 2008 is the same codebase bits as Vista. It is available in two flavors 32 bit and
64 bit versions.
**Windows Server 2008 R2 is the same codebase bits as Windows 7 x64. It is only available in the
64 bit version.
In Simple terms..
Windows Server 2008 is the same codebase bits as Vista. It is available in two flavors 32 bit
and 64 bit versions.
Windows Server 2008 R2 is the same codebase bits as Windows 7 x64. It is only available in
the 64 bit version.
Windows Server 2012 Schema version is 56 and Windows Server 2012 R2 is 69, schema
will be updated while doing Forest preparation/installing Windows Server 2012 R2
Active Directory comes first when I think about windows server, will start with Active Directory
new features on Windows Server 2012 R2
Windows Server
2008 Windows Server 2008 R2
It is based on kernal
version 6.0 ( the
It is based on kernal version 6.1 ( the same of Windows 7)
same of Windows
Vista)
It use the same GUI
introduced with It use the same new GUI introduced with Windows 7
Windows Vista
It is only having Basic Microsoft RemoteFX, introduces a new set of remote user-
Remote desktop experience capabilities that enable a media-rich user
Services. environment for virtual and session-based desktops.
Windows Server 2008 uses NT 6.0 SP1 kernel, like Windows Vista SP1
Windows Server 2008 R2 uses NT 6.1 kernel, like Windows 7
Windows Server 2012 uses NT 6.2 kernel, like Windows 8
Windows Server 2012 R2 uses 6.3 kernel, like NT Windows 8.1
When your domain is registered, its assigned several DNS records, which enable it to be located on the
Internet. These include MX records, which direct the domains mail flow. Each MX record points to an
email server thats configured to process mail for that domain. Theres typically one record that points to a
primary server, then additional records that point to one or more backup servers. For users to send and
receive email, their domain's MX records must point to a server that can process their mail.
To filter email through the message security service, you must insert new records that point to the
message security service's servers.
For more about MX records, watch the video Understanding and Working with MX Records
5. Click Lookup.
For detailed instructions on how to update your MX records, see Change Your MX Records
Why should I update MX records?
For the message security service to work, we need you to route your mail to us. When you update your
MX records, we accept your mail, filter out the bad mail, and pass the good mail on to your server.
If you're adding more domains later on, update your MX records after you've added the domain in the
Administration Console. Until your domain is set up in the Administration Console, mail will bounce if you
update your MX records.
TTL: "Time to Live." How long it will take to update the record. This is measured in seconds. A TTL of
3600 seconds means records will take an hour to update. A TTL of 86400 means records will take a day
to update. A higher TTL value means less traffic load for the DNS server, but it also means that changing
the MX records will take longer.
Preference or Priority: The order of preference for mail delivery. Sending servers should try the lowest
preference number first, then the next lowest, and so on.
Data: The host name of the mail server that handles mail for that domain.
For instance, if your domain is jumboinc.com, your MX records might look like this:
Every DNS host has a different user interface for MX records. Some use a trailing period and some don't.
Some allow you to set your TTL and some won't. Our instructions include information for most common
MX hosts, but yours may be different. If you're not sure what to enter, use the same format as your
existing MX records. Be sure that the message security service MX records have the first priority; the
exact numbers don't matter as long as the message security service MX records are the first. If your DNS
server allows fewer than 4 records, enter as many as you can.
For detailed instructions on how to update your MX records, see Change Your MX Records.
Should I update A records when routing mail to the message security service?
Do not update your A records. Since your MX records point to psmtp.com, you do not need to change any
A records.
A Records
A Records are the most basic type of DNS record and are used to point a
domain or subdomain to an IP address. Assigning a value to an A record is
as simple as providing your DNS management panel with an IP address to
where the domain or subdomain should point and a TTL.
You would want to use an A Record for your DNS entry if you have an IP
address that the domain/subdomain should point to or if you want to
establish a domain/subdomain to be used as the place to point a
CNAME. You can find out more about why you might want to do this in the
CNAME portion of this article.
CNAME
CNAME records are another commonly used type of DNS entry and are
used to point a host/name to another host/name.
In the screenshot above, you can see immediately that one of the
important differences from A Records is that the value portion of the
record is required to be an existing subdomain/domain. You can see that
the journal host/name points to my blog.iamrobertv.com A Record,
which points to 198.101.164.57. What this means is that if I ever changed
the value of the blog subdomain, then the journal subdomain will also
inherently have its value changed.
MX Record
Mail Exchanger (MX) records are used to help route email according the
domain owners preference. The MX record itself specifies which server(s)
to attempt to use to deliver mail to when this type of request is made to
the domain. They differ from A Records and CNAMEs in the way that they
also require a priority value as a part of their entry. The priority number
is used to indicate which of the servers listed as MX records it should
attempt to use first.
In the screenshot above, you can see that I am using two MX records that
have separate priority values and point to different subdomains. These
subdomains are pointed at two different email servers that are
designated to handle email. The MX record with the lower priority number
(0 in this case) is the first to be tried for email delivery. If this server is
unable to handle the mail request, the next lowest priority number is
used, which in this case would be 10.
Some email providers have only one MX record and some have well over
two. The number of MX entries you will need to create depends largely on
the mail provider and how they expect the load on these email servers to
be handled.
Youll notice the host name here is designated as the naked/primary form
( @ ). If you wanted to receive mail on a subdomain, you would adjust the
host/name accordingly and ensure your email provider is setup to handle
email from the subdomain.
TXT Record
A TXT record is used to store any text-based information that can be
grabbed when necessary. We most commonly see TXT records used to
hold SPF data and verify domain ownership.
TXT Record listing in the GoDaddy DNS Management Panel.
We wont go into the details of properly formed SPF records and what
their different pieces mean, but these will commonly be supplied to you
by the mail provider you are working with. In the same way, places that
require domain verification through use of a TXT record will also provide
you with a properly formatted TXT record value to use.
2. On the New receive connector page, specify a name for the Receive connector and
then select Frontend transport for the Role. Since you are receiving mail from the
Internet in this case, we recommend that you initially route mail to your Front End
server or servers, to simplify and consolidate your mail flow.
3. Choose Internet for the type. The Receive connector will receive mail from Internet
senders.
4. For the Network adapter bindings, observe that All available IPV4 is listed in
the IP addresses list and the Port is 25. (Simple Mail Transer Protocol (SMTP) uses
port 25.) This indicates that the connector listens for connections on all IP addresses
assigned to network adapters on the local server.
Once you have created the Receive connector, it appears in the Receive connector list.
When install your first Exchange Server 2016 server, the server isn't able to send mail
outside of your Exchange organization. To send mail outside your Exchange organization,
you need to create a Send connector.
o Name Enter a descriptive name for the Send connector, for example, To
Internet.
3. On the next page, verify that MX record associated with recipient domain is
selected. This means the connector uses DNS on the Internet to route mail, as
opposed to routing all outbound mail to a smart host. For information about creating
a Send connector that uses smart host routing, see Create a Send connector to route
outbound mail through a smart host.
o In the Address space section, click Add . In the Add domain dialog box
that appears, in Fully Qualified Domain Name (FQDN), enter an asterisk
(*), and then click Save. This value indicates that the Send connector applies
to messages addressed to all external domains.
5. On the next page, in the Source server section, click Add . In the Select a
Server dialog box that appears, select one or more Mailbox servers that you want to
use to send mail to the Internet. If you have multiple Mailbox servers in your
environment, select the ones that can route mail to the Internet. If you have only one
Mailbox server, select that one. After you've selected at least one Mailbox server,
click Add, click OK, and then click Finish.
After you create the Send connector, it appears in the Send connector list.
o Disabled
o Enforced
The following instructions will show you how to create a rule in Office 365 that will prevent your domain
from being spoofed from outside your environment.
1. Delete any inbound emails that originate from OUTSIDE your organization that are set to look like
they come from your domain. (domain spoof protection)
2. Allow emails from KnowBe4s servers to bypass this rule (so phishing tests can be conducted that
look like they are coming from internal email accounts).
Note: This rule will only protect your users from outsiders who are trying to spoof your domain. It will not
affect an external email from being sent using your domain to another email address (not to your
company). For simplicitys sake, it will prevent emails from being sent to your users from outside your
company that look like they are originating from within your company. But it will not prevent a person from
sending someone else outside your company an email that looks like it comes from your company. That is
typically handled with SPF record management which is not covered in this document.
Across all sites, you can identify any document containing a health
record thats shared with people outside your organization, and
then automatically block access to that document for everyone
except the primary site collection administrator, document owner,
and the person who last modified the content.
You can educate your users about DLP policies and help them
remain compliant without blocking their work. For example, if a
user tries to share a document containing sensitive information, a
DLP policy can both send them an email notification and show
them a policy tip in the context of the document library that allows
them to override the policy if they have a business justification.
The same policy tips also appear in Excel 2016, PowerPoint 2016,
and Word 2016.
Permissions
Members of your compliance team who will
create DLP policies need permissions to the
Security & Compliance Center. By default, your
tenant admin will have access to this location
and can give compliance officers and other
people access to the Security & Compliance
Center, without giving them all of the
permissions of a tenant admin. To do this, we
recommend that you:
1. Create a group in Office 365 and add compliance officers to it.
What is DLP?
Data Loss Prevention is the capability to monitor potential data breaches inside your organization that
must comply with a set of policies. It allows a system to control and block sensitive information from
leaving an organization.
In Office 365, the platform helps you to identify, track and protect sensitive information in your
organization through deep content analysis and makes it easy to setup the policies. The DLP capability
applies to content in Exchange Online, SharePoint Online and OneDrive for Business services on Office
365.
In Office 365, the DLP capability is only available in the following subscription plans:
Enterprise E3
Enterprise E4
Government E3
Government E4
Nonprofit E3
Nonprofit E4
Setup of DLP policies
Administrators enable and manage this capability in the Admin portal of Office 365. In the Admin portal on
the left navigation (figure 1), go to Admin and then select Compliance.
Benefits of DLP
The DLP offerings in Office 365 let businesses quickly and easily comply with various industry or
government standards without making a big expensive investment. Which in the end puts you and your
organization in a much better place. It provides easier control over auditing information exchange inside
your organization. It will also keep the Security Officers more relaxed in your organization!
The DLP policies provide Policy Tips to your end users without affecting their productivity and allows
users to get educated into being compliant with organizational policies. There are more benefits to list
here, but you get the idea by now.
Repadmin has been a mainstay in the Windows toolbox since Windows 2000
was introduced, and its perhaps the most robust tool for troubleshooting
Active Directory replication issues, such as fixing lingering objects. As a staple
in Microsofts Windows Support Tools, Repadmin is available in many of the
more recent versions of Windows Server, including:
OU, DC=company,DC=com"
In the output, there is a section for the command running on each DC. If
the attributes are listed, the object has been replicated. But if an error
occurs, such as DsReplicaGetInfo() failed with status 8333, then the object
has not yet been replicated to that DC.
The example below replicates the configuration naming context from WTet-
DC2 to Wtec-DC4. Note that the naming context is specified in
distinguished name (DN) format:
cn=configuration,dc=wtec,dc=adapps,dc=hp,dc=com
Another command that uses the expert help feature in Repadmin is: /add
<Naming Context> <Dest DC> <Source DC> [/asyncrep] [/syncdisable]
Its most useful when dcpromo doesnt work due to a replication failure. For
instance, if there is only one-way replication after using dcpromo, or if the
SYSVOL and NETLOGON shares dont show up after dcpromo reboots the
machine, this command can be used to build a low-level replication link.
However, the syntax isnt specified in the help feature, so admins must use the
DNS, CNAME as the argument in the DestDC and SourceDC arguments. Just
copy/paste from the DNS management snap-in for the respective servers and
enter the naming context in DN format.
In the example below, dcpromo fails on the DC beginning with f3632fb7. The
other DC in the command is any other good DC (preferably in the same
site/subnet).
f90e-45f8-b165-1d5552013489._msdcs.wtec.adapps.hp.com f3632fb7-1baa-4034-
b765-d9b509fb36 e2._msdcs.wtec.adapps.hp.com
Remember, this command only works if something is broken. Executing it on a
perfectly good DC will produce an error message because a naming context
cannot be added to a DC where it already exists.
DC4.Wtec.adapps.hp.com
dc=emea,dc=company,dc=com
Remember, this command is not a fool-proof fix and doesnt always do the job.
For the best results, make sure the StrictReplication regkey is enabled on all
DCs to prevent lingering objects from returning. Its also important to run this
command on all naming contexts when working with multiple domain forests,
and keep checking for lingering object-related events in the event log to make
sure they are gone.
These are just some of the commands admins can use when working with
Repadmin and can be best learned by implementing them in a lab
environment. There are several other resources that discuss the ins and outs
of Repadmins as well. Start by reading the ExpertHelp files to learn several
other commands that were not covered here. Youll be glad you did.