Overview: Dynamic configuration of security-group membership for Azure Active Directory is available in public preview. Administrators can set rules for groups that are created in Azure Active Directory based on user attributes (such as department and country). This allows members to be automatically added to or removed from a security group. These groups can be used to provide access to applications or cloud resources (such as SharePoint sites and documents) and to assign licenses to members. There is no additional charge for this feature. For more information, please visit Dynamic memberships for groups in Azure AD.
If you are familiar with SharePoint Target Audience or Claims based role and access, this Azure AD dynamic membership for groups is not new to you, this is only a different way to consume but this Azure feature will allow organisation to plan their role-based authentication and authorisation for Azure hosted application which includes PAAS and IAAS, Office 365 hosted application like exchange, sharepoint or dynamic 365 CRM application.
You will be able to create AD group add users dynamically based on their AD attribute like Department, location, business area etc. once you created these AD groups you will be able to use this group to assign permission or target content with in the Azure and office 365 applications.
You can set up a rule for dynamic membership on security groups or Office 365 groups. Nested group memberships aren’t currently supported for group-based assignment to applications.+
Dynamic memberships for groups require an Azure AD Premium license to be assigned to+
- The administrator who manages the rule on a group
- All members of the group
- In the Azure classic portal, select Active Directory, and then open your organization’s directory.
- Select the Groups tab, and then open the group you want to edit.
- Select the Configure tab, select the Advanced rule option, and then enter the advanced rule into the text box.
Containing twenty-four design patterns and ten related guidance topics, this guide articulates the benefit of applying patterns by showing how each piece can fit into the big picture of cloud application architectures. It also discusses the benefits and considerations for each pattern. Most of the patterns have code samples or snippets that show how to implement the patterns using the features of Microsoft Azure. However the majority of topics described in this guide are equally relevant to all kinds of distributed systems, whether hosted on Azure or on other cloud platforms.
Problem: When you access web application with in the SharePoint sever, it keeps on prompting for authentication.
Solution: Disable Loop Back Check
The following step has to be followed to disable the loop back check in SharePoint Servers,
Step 1: Open the Registry Editor (regedit)
Step 2: Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa in registry
Step 3: Create the dword32 for DisableLoopbackCheck
Step 4: modify the value to 1
Recommended Option: Run this power shell command
New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name “DisableLoopbackCheck” -value “1” -PropertyType dword
You may have to restart the servers and will have run this from all of your SharePoint servers.
I came to a scenario to migrate the Box content to SharePoint (Office 365). The cost effective solution is the BOX site/folder owners can use the SharePoint Library Open with Explorer features to move the files from Box to SharePoint Online.
If you would like to automate the process for large content, there are many 3rd party Tools are available in market. I explored the skysync http://www.skysync.com/ which is very straight forward to migrate the content from Box to SharePoint or SharePoint to Box.
Skysync software can be used to Sync or Migrate Files between SharePoint, Box, Office 365, Huddle, Dropbox, Network File Systems & more!
Skysync software is available in 3 editions (Pro, Business and Enterprise) , prices and features are different is each model.
It is very easy to setup a new job for sync or migration. The details features can be find here.
This article helps you to install SharePoint Server 2016 (Preview), I am using Azure VM for this demo/article and I will install Single-Server installation of SharePoint Server 2016 with Database server. I am not seeing any major different in this release with respect the Installation.
Note: In this example, I am using SQL server and SharePoint in single VM
- VM 1: Active Directory & DNS
- VM 2: SharePoint and SQL Server – Single Server Farm
- SQL Server 2014 SP1
- SharePoint Server 2016 – Preview
Service Accounts and Permissions
The following article provides information about the administrative and service accounts that you need for an initial SharePoint Server 2016 IT Preview deployment. Additional accounts and permissions are required to fully implement all aspects of a production farm.
The following article describes SharePoint administrative and services account permissions for the following areas: Microsoft SQL Server, the file system, file shares, and registry entries.
The installation phase contain the following procedures,
- SQL Server Installation
- SharePoint Server 2016
SQL Server Installation
The following steps will be followed to install the SQL Server 2014 SP1,
Login to the VM with SharePoint Setup account
Mount the SQL Server ISO file, if you already download the ISO file on the VN where you want to install SharePoint.
Run the SQL Server Setup EXE.
Click the “Installation” tab
Click the “New SQL Server stand-alone installation or add features to an existing installation”
On the Product Key page, enter the valid licence key. Note: If you are using MSDN subscription the key will be included in the ISO file.
The “SQL server feature installation” is selected by default so don’t change since we are trying to setup SQL server for SP 2016.
Please select only the relevant features, since its Dev/Test VM I have selected all features.
Note: Database Engine service is must.
Select Default instance.
Data base Engine Instance( https://msdn.microsoft.com/en-us/library/hh231298.aspx)
Add the SharePoint Setup Account (select Add Current User).
Once SQL server is installed successfully, Start the SharePoint Installation. This SP 2016 installation is not changed much from SP 2013.
SharePoint Server 2016 Installation
The following steps will be followed to install the SharePoint 2016 Pre-requisite,
Run the Pre-requisite EXE using SharePoint Setup Account.
The prerequisites has to be installed first before the installation of SharePoint Server 2016, the prerequisites installation can ask for restart multiple time. Start the prerequisites installation as shown below,
Run the SharePoint Server setup exe, once the Pre-requisite installed successfully.
Enter key “NQTMW-K63MQ-39G6H-B2CH9-FRDWJ” for SharePoint Server 2016 Preview release.
Service Application & Services Configuration Wizard
SharePoint 2016 – Central Administrator
SharePoint Server 2016 IT Preview has been designed, developed, and tested with the Microsoft Software as a Service (SaaS) strategy at its core. Drawing extensively from that experience, SharePoint Server 2016 IT Preview is designed to help you achieve new levels of reliability and performance and empower users while meeting their demands for greater business mobility.
The TechNet library contains articles that describe how to plan for, deploy, and use all the features of SharePoint Server 2016 IT Preview.
- Explore SharePoint Server 2016 IT Preview
- Plan for SharePoint Server 16 IT Preview
- Install and configure SharePoint Server 16 IT Preview
- Technical reference for SharePoint Server 2016 IT Preview
The following identity models are support in Office 365 and depend on our requirement these models will be used,
- Office 365 Cloud Identity
- Office 365 Synchronized Identity
- Office 365 Federated Identity
Office 365 Cloud Identity: If you are new starter to Office 365 and you don’t have requirements to use your on-premises Active Directory identity store, then this model is right for you .In this model a user is created and managed in Office 365 and stored in Azure Active Directory, and the password is verified by Azure Active Directory. Azure Active Directory is the cloud directory that is used by Office 365. There is no equivalent user account on-premises, and there is nothing that needs to be configured to use this other than to create users in the Office 365 admin center.
Office 365 Synchronized Identity: In this model the user identity is managed in an on-premises server and the accounts and password hashes are synchronized to the cloud. The user enters the same password on-premises as they do in the cloud, and at sign-in the password is verified by Azure Active Directory. This model uses the Microsoft Azure Active Directory Sync Tool (DirSync).
Note: Most of the organisation has restriction on storing the password in cloud/ external store. If you these restriction use/implement the Office 365 Federated Identity.
Office 365 Federated Identity: This model requires a synchronized identity but with one change to that model: the user password is verified by the on-premises identity provider. This means that the password hash does not need to be synchronized to Azure Active Directory. This model uses Active Directory Federation Services (AD FS) or a third- party identity provider.
When to choose the Cloud Identity model
Choosing cloud-managed identities enables you to implement the simplest identity model, because there is no on-premises identity configuration to do. All you have to do is enter and maintain your users in the Office 365 admin center. This is likely to work for you if you have no other on-premises user directory, and I have seen organizations of up to 200 users work using this model.
You may also choose the Cloud Identity model if you have a very complex on-premises directory and simply want to avoid the work to integrate with it. These complexities may include a long-term directory restructuring project or complex governance in the directory. If you have an existing on-premises directory, but you want to run a trial or pilot of Office 365, then the Cloud Identity model is a good choice, because we can match users when you want to connect to your on-premises directory.
It is most common for organizations with an existing on-premises directory to want to sync that directory to the cloud rather than maintaining the user directory both on-premises and in Office 365. In that case, either password synchronization or federated sign-in are likely to be better options, because you perform user management only on-premises.
To sum up, you would choose the Cloud Identity model if you have no on-premises directory, if you have a very small number of users, if your on-premises directory is undergoing significant restructuring, or if you are trialing or piloting Office 365.
When to use the Synchronized Identity model
The Synchronized Identity model is also very simple to configure. It requires you to have an on-premises directory to synchronize from, and it requires you to install the DirSync tool and run a few other consistency checks on your on-premises directory. This is described in my recent blog post Synchronizing your directory with Office 365 is easy. Before June 2013 this model did not include password synchronization and users provisioned using synchronized identity had to create new cloud passwords for Office 365. This was a strong reason for many customers to implement the Federated Identity model. Now that password synchronization is available, the Synchronized Identity model is suitable for many customers who have an on-premises directory to synchronize with and their users will have the same password on-premises and in the cloud.
In addition to leading with the simplest solution, we recommend that the choice of whether to use password synchronization or identity federation should be based on whether you need any of the advanced scenarios that require federation. I’ll talk about those advanced scenarios next. However if you don’t need advanced scenarios, you should just go with password synchronization. You can also use the Synchronized Identity model when you ultimately want federated identity, but you are running a pilot of Office 365 or for some other reason you aren’t ready to dedicate time to deploying the AD FS servers yet.
To sum up, you would choose the Synchronized Identity model if you have an on-premises directory and you don’t need any of the specific scenarios that are provided for by the Federated Identity model.
When to use the Federated Identity model
As mentioned earlier, many organizations deploy the Federated Identity model just so that their users can have the same password on-premises and in the cloud. With the addition of password hash synchronization to the Synchronized Identity model in July 2013, fewer customers are choosing to deploy the Federated Identity model, because it’s more complex and requires more network and server infrastructure to be deployed.
All of the configuration for the Synchronized Identity model is required for the Federated Identity model. Because of this, we recommend configuring synchronized identity first so that you can get started with Office 365 quickly and then adding federated identity later.
The following scenarios are good candidates for implementing the Federated Identity model. If none of these apply to your organization, consider the simpler Synchronized Identity model with password synchronization.
The Microsoft Azure Preview Portal automatically creates a pre-configured SharePoint Server 2013 farm for us. This can save you a lot of time when we need a basic or high-availability SharePoint farm for a development and testing environment.
The basic SharePoint farm consists of three virtual machines in this configuration.
We can use this farm configuration for a simplified setup for SharePoint app development or first-time evaluation of SharePoint 2013.
The high-availability SharePoint farm consists of nine virtual machines in this configuration.
We can use this farm configuration to test higher client loads, high availability of the external SharePoint site, and SQL Server AlwaysOn for a SharePoint farm. We can also use this configuration for SharePoint app development in a high-availability environment.
Microsoft Azure Preview Portal: