DirSync vs Azure AD Sync vs Azure AD Connect

DirSync, Azure AD Sync and Azure AD Connect are used to sync on-premises Active Directory to cloud based directory service like Azure AD instance, Office 365, Dynamics Online and other Microsoft Cloud Services

All are used for Single Sign-On (SSO) and user can use the a single user account and password to access there cloud based application on Office 365, Dynamics Online and Azure AD, we can synchronize user account and there passwords

Single sign-on (SSO)
Single sign-on (SSO) is a session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications. The service authenticates the end user for all the applications the user has been given rights to and eliminates further prompts when the user switches applications during the same session. On the back end, SSO is helpful for logging user activities as well as monitoring user accounts.
Example : Microsoft, Google (if you sign into email, you can also access other applications with out entering username and password.) . To make it more secure , service providers are using Multifactor authentication where required.

DirSync
DirSync to sync your local on-premises Active Directory with cloud based services. dirsync doesn’t support multi-forest environments.


Azure AD Sync
Azure AD Sync is advance version of DirSync, it support most of the functions of traditional DirSync, and adds extra functionality such as mutli-forest support and password write back. It’s more flexible then Dir Sync

Azure AD Connect
Azure AD Connect will integrate your on-premises directories with Azure Active Directory. This allows you to provide a common identity for your users for Office 365, Azure, and SaaS applications integrated with Azure AD.
Azure AD Connect has many of the same features as DirSync and Azure AD Sync, its going to replace DirSync and Azure AD Sync and it has plans for many other features such as non-AD LDAP support.
Azure Connect is recommended for larger organizations that have greater flexibility requirements, it provides consistent experience in hybrid environments that may or may not entirely utilize Microsoft on premise solutions


Why use Azure AD Connect?
Azure AD Connect is the best way to connect your on-premises directory with Azure AD and Office 365. This is a great time to upgrade to Azure AD Connect from Windows Azure Active Directory Sync (DirSync) or Azure AD Sync as these tools are now deprecated and will reach end of support on April 13, 2017.
Integrating on-premises directory service with Azure AD makes your users more productive by providing a common identity for accessing both cloud based and on-premises service and application.


Advantages:

• Companies can provide users with a common hybrid identity across on-premises or cloud-based services with Windows Active Directory and then connecting to Azure Active Directory.
• Administrators can use multi-factor authentication to provide conditional access based on application, device and user identity, network location and many more.
• Users can use their user accounts in Azure AD to access Office 365, Microsoft Intune, SaaS apps and any other third-party applications.
• Application can be developed with common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure Active Directory Connect Sync
The Azure Active Directory Connect synchronization services (Azure AD Connect sync) is a main component of Azure AD Connect. It takes care of all the operations that are related to synchronize identity data between your on-premises environment and Azure AD. Azure AD Connect sync is the successor of DirSync, Azure AD Sync, and Forefront Identity Manager with the Azure Active Directory Connector configured.

Azure AD Connect and federation
Azure Active Directory (Azure AD) Connect lets you configure federation with on-premises Active Directory Federation Services (AD FS) and Azure AD. With federation sign-in, you can enable users to sign in to Azure AD-based services with their on-premises passwords--and, while on the corporate network, without having to enter their passwords again. By using the federation option with AD FS, you can deploy a new installation of AD FS, or you can specify an existing installation in a Windows Server 2012 R2 farm.

Vsto Excel Addin project debug error "you cannot debug or run this project, because the required version of the microsoft office application is not installed"

If you have upgraded your office from 2013 to 2016 and after upgrade, if you want to debug your Excel-addin project, you will receive the below error.

you cannot debug or run this project, because the required version of the Microsoft office application is not installed

This issue is because in your project properties, target Office version is pointing to 2013 i.e 15.0 , you need to replace the 15.0 with 16.0 then it will work.

Select your   project in the solution explorer, then unload the project, then again  click on Edit your Excel-addin project after unloading as shown in the below window

 

The project file will be opened for editing. go to the below Tag line and replace 15.0 with 16.0. as shown below

        <ProjectProperties HostName="Excel" HostPackage="{29A7B9D7-A7F1-4328-8EF0-6B2D1A56B2C1}" OfficeVersion="15.0" VstxVersion="4.0" ApplicationType="Excel" Language="cs" TemplatesPath="VSTOTemplates" DebugInfoExeName="#Software\Microsoft\Office\15.0\Excel\InstallRoot\Path#excel.exe" DebugInfoCommandLine="/x " AddItemTemplatesGuid="{51063C3A-E220-4D12-8922-BDA915ACD783}" />

Reload the project and Set it as start up project  then start debugging..! it should work now.

ADFS Setup.

Software requirements

• AD FS relies on server functionality that is built into the Windows Server® 2012 operating system.
• The Federation Service and Federation Service Proxy role services cannot coexist on the same computer.

Setup Roles and Features

• Go to Local Server tab, scroll down to the ROLES AND FEATURES section, then click TASKS->Add Roles and Features.
• In Add Roles and Features Wizard, click Next to continue.
• On next screen, keep Role-based or feature-based installation checked, click Next to continue.
• On Server selection screen, accept default settings and click Next.
• On Server Roles screen, check Active Directory Domain Service. This will pop up a dialog prompting to enable required features. Click Add Features to continue.
• Check Active Directory Federation Services. Again, click Add Features in the pop-up to add required features.
• Click Next all the way till the end of the wizard workflow, accepting all default settings.
• Click Install to continue. Once installation completes, click Close to close the wizard.

Configure AD and Domain controller
Now you’ll see a warning icon reminding you some additional configurations are needed

• Click on the icon and click on the second item, which is Promote this server to a domain controller.
• In Active Directory Domain Services Configuration Wizard, select Add a new forest, enter “your domain name” as Root domain name, and then click Next to continue.
• On next screen, provide a DSRM password. Uncheck Domain Name System (DNS) server as we don’t need this capability in our scenario (this is an all-in-one forest anyway). Click Next to continue.
• Keep clicking Next till Install button is enabled. Then click Install.
• The machine reboots.
• Create Some Test Accounts
• Before we move forward, let’s create a couple of user groups and a couple of test accounts.
• Launch Active Directory Users and Computers (Window + Q, then search for “users”).
• Right-click on Users node, then select New->Group:
• In New Object window, enter Manager as group name, and change Group scope to Domain local:
• Follow the same step, create a Staff group. Right-click on Users node, then select New->User to create a new user:
• Set up a password for the user, then finish the wizard. On a test environment, you can disallow password change and make the the password never expire to simplify password management:
• Double-click on the user name, and add the user to Manager group:
• Create another user, and add the user to Staff group.

Configure SSL Certificate

• Launch Internet Information Services Manager (Window + Q, then search for “iis”).
• Select the server node, and then double-click Server Certificates icon in the center pane.
• In the right pane, click on Create Self-Signed Certificate… link. Give a friendly name to the cert, for example haishidc2.cloudapp.net. Click OK. If you open the cert, you can see the cert is issued to [your virtual machine name].cloudapp.net. This is the reason why we used cloudapp.net domain name.

Configure ADFS Server

• Go back to Server Manager. Click on the warning icon and select Run the AD FS Management snap-in.
• Click on AD FS Federation Server Configuration Wizard link in the center pane.
• In AD FS Federation Server Configuration Wizard, leave Create a new Federation Service checked, click Next to continue.
• On next screen, keep New federation server farm checked, click Next to continue.
• On next screen, You’ll see our self-issued certificate is automatically chosen. Click Next to continue.
• On next screen, setup Administrator as the service account. Click Next. Click Next to complete the wizard.

Configure Trust Relationship with ACS – ADFS Configuration

• Configure ADFS as a trusted Identity Provider of your ACS namespace. The trust relationship is mutual, which means it needs to be configured on both ADFS side and ACS side. From ADFS side, we’ll configure ACS as a trusted relying party. And from ACS side, we’ll configure ADFS as a trusted identity provider. Let’s start with ADFS configuration.
• Back in AD FS Management snap-in, click on Required: Add a trusted relying party in the center pane.
• In Add Relying Party Trust Wizard, click Start to continue.
• Paste in the ACS ws-Federation metadata URL you got from your ACS namespace , and click Next to continue
• Keep clicking Next, then finally Close to complete the wizard.
• This brings up the claim rules window. Close it for now.
• Back in the main window, click on Trust Relationships->Claims Provider Trust node. You’ll see Active Directory listed in the center pane. Right-click and select Edit Claim Rules…
• In the Edit Claim Rules for Active Directory dialog, click Add Rule… button.
• Select Send Group Membership as a Claim template. Click Next.
• On next screen, set the rule name as Role claim. Pick the Manager group using the Browse… button. Pick Role as output claim type. And set claim value to be Manager. Then click Finish. What we are doing here is to generate a Role claim with value Manager for all users in the Manager group in our AD.
• Add another rule, and this time select Send LDAP Attribute as Claims template.
• Set rule name as Name claim. Pick Active Directory as attribute store, and set up the rule to map Given-Name attribute to Name claim
• Back in the main window, click on Trust Relationships->Relying Party Trusts node. You’ll see your ACS namespace listed in the center pane. Right-click on it and select Edit Claim Rules…
• Add a new rule using Pass Through or Filter an Incoming Claim template.
• Pass through all Role claims
• Similarly, add another pass-through rule for Name claim.
• Now our ADFS server is configured to trust our ACS namespace, and it will issue a Name claim and a Role claim for authenticated users.

References:

http://technet.microsoft.com/en-US/ff678034%28WS.10%29.aspx  
http://haishibai.blogspot.com/2012/11/complete-walkthrough-setting-up-adfs-20.html
http://technet.microsoft.com/en-us/evalcenter/ee476597.aspx
http://msdn.microsoft.com/en-us/library/bb897402.aspx

How to Impersonate the logged in user on SQL server from a Web App.

Recently , We have developed an OData service which is On premise and using Windows authentication

When I have tested my web application using IIS Express, it worked fine for me. my web app able to connect to the SQL server using my windows credentials.

But When I have deployed my solution on IIS, then the Web App is failing with the error that is saying that Domain\MachineName failed to connect to the SQL server.

I tried to Dig into the Solution.

First I have found that When your application pool runs under ApplicationPoolIdentity, it will try to authenticate the remote system (Domain\Machine) against the SQL server and fails.

I have enabled Windows Authentication and Asp.Net Impersonation on the Web Application and changed the Application Pool Identity of my web application to Local System. Then it is working fine.

These are the changes you have to make to your web.config

<system.web>

    <authentication mode="Windows"  ></authentication>

    <identity impersonate="true"/>

  </system.web>
And you need to enable Windows Authentication and Asp.Net Impersonation on your Web application On IIS



You might see the below exception, once you have changed the web.config

HTTP Error 500.24 - Internal Server Error

An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

Most likely causes:

• system.web/identity@impersonate is set to true.

then add the below line of code which is in bold to your web config

<system.web>

    <compilation debug="true" targetFramework="4.5" />

    <httpRuntime targetFramework="4.5" />

    <authentication mode="Windows"  ></authentication>

    <identity impersonate="true"/>

  </system.web>

  <system.webServer>

    <validation validateIntegratedModeConfiguration="false" />

 </system.webServer>

Question to the readers: Why does it worked for me when I am using IIS express.