To understand the security we need to understand the following term
Business Unit - BU is nothing but a teritory in MS CRM like in If we say India is a Parent BU or root BU and then Bihar , Karnataka, Delhi ie all states are BU. We cannot delete parent BU.
Role-based Security
Object-based Security
Roles – User
Global Admin – Access to use all the features of ms crm .
Customised Adminstrtor – (Billing admin, Axchange Admin , Password Adminstrator, user management) Total 7
=================================================
Sharing a record
https://msdn.microsoft.com/en-in/library/dn481569.aspx
Record-based security in Microsoft Dynamics 365 and Microsoft Dynamics 365 (online) applies to individual records. It is provided by using access rights.
The relationship between an access right and a privilege is that access rights apply only after privileges have taken effect. For example, if a user does not have the privilege to read accounts, that user is unable to read any account, regardless of the access rights another user might grant to a specific account through sharing.
In This Topic
Access rights
Sharing records
Assigning records
Retrieving the access rights for a record
Dependencies between access rights
Access rights
An access right is granted to a user for a particular record. The following table lists the descriptions for these access rights.
Access right AccessRights enumeration value Description
Read ReadAccess Controls whether the user can read a record.
Write WriteAccess Controls whether the user can update a record.
Assign AssignAccess Controls whether the user can assign a record to another user.
Append AppendAccess Controls whether the user can attach another record to the specified record.
The Append and Append To access rights work in combination. Every time that a user attaches one record to another, the user must have both rights. For example, when you attach a note to a case, you must have the Append access right on the note and the Append To access right on the case for the operation to work.
Append To AppendToAccess Controls whether the user can append the record in question to another record.
The Append and Append To access rights work in combination. For more information, see the description for Append.
Share ShareAccess Controls whether the user can share a record with another user or team. Sharing gives another user access to a record. For more information, see Sharing records.
Delete DeleteAccess Controls whether the user can delete a record.
Create access
The right to create a record for an entity type is not included in the previous table because this right does not apply to an individual record, but instead to a class of entities. Create is handled as a privilege instead of as an access right. The user who creates a record has all rights on that record, unless his or her other privileges forbid a specific right.
The Create privilege controls whether you can create a record. If you have the Create privilege with Local, Deep, or Global access, you can create records for other users. If you have Create and Read privileges with Basic access, you can create records for yourself.
For more information about dependencies that relate to create privileges, see Dependencies between access rights.
Sharing records
Sharing lets users give other users or teams access to specific customer information. This is useful for sharing information with users in roles that have only the Basic access level. For example, in an organization that gives salespeople Basic read and write access to accounts, a salesperson can share an opportunity with another salesperson so that they can both track the progress of an important sale.
For security reasons, develop the practice of sharing only the necessary records with the smallest set of users possible. Only grant the minimum access required for users to do their jobs.
Microsoft Dynamics 365 provides the following sharing capabilities:
• Share. Any user who has share privileges on a given entity type can share records of that type with any other user or team in Microsoft Dynamics 365. To share a record, use GrantAccessRequest.
When you share a record with another user, indicate what access rights (Read, Write, Delete, Append, Assign, and Share) you want to grant to the other user. Access rights on a shared record can be different for each user with whom the record is shared. However, you cannot give a user any rights that he or she would not have for that type of entity, based on the role assigned to that user. For example, if a user does not have Read privileges on accounts and you share an account with that user, the user will be unable to see that account.
• Modify share. You can modify the rights granted to a shared record after it has been shared. To modify sharing for a record, use the ModifyAccessRequest.
• Remove share. If you share a record with another user or team, you can stop sharing the record. After you remove sharing for a record, the other user or team loses access rights to the record. To remove sharing for a record, use the RevokeAccessRequest.
Tip
Use GrantAccessRequest, ModifyAccessRequest, and RevokeAccessRequest for sharing.
A user might have access to the same record in more than one context. For example, a user might share a record directly with specific access rights, and he or she might also be on a team in which the same record is shared with different access rights. In this case, the access rights that this user has on the record are the union of all the rights.
For a list of entities that support sharing, see the GrantAccessRequest.
Sharing and inheritance
If a record is created and the parent record has certain sharing properties, the new record inherits those properties. For example, Joe and Mike are working on a high priority lead. Joe creates a new lead and two activities, shares the lead with Mike, and selects cascade sharing. Mike makes a telephone call and sends an email regarding the new lead. Joe sees that Mike has contacted the company two times, so he does not make another call.
Sharing is maintained on individual records. A record inherits the sharing properties from its parent and also maintains its own sharing properties. Therefore, a record can have two sets of sharing properties—one that it has on its own and one that it inherits from its parent.
Removing the share of a parent record removes the sharing properties of objects (records) that it inherited from the parent. That is, all users who previously had visibility into this record no longer have visibility. Child objects still could be shared to some of these users if they were shared individually, not from the parent record.
Assigning records
Anyone with Assign privileges on a record can assign that record to another user. When a record is assigned, the new user or team becomes the owner of the record and its related records. The original user or team loses ownership of the record, but automatically shares it with the new owner.
In Microsoft Dynamics 365, the system administrator can decide for an organization whether records should be shared with previous owners or not after the assign operation. If Share with previous owner is selected, then the previous owner shares the record with all access rights after the assign operation. Otherwise, the previous owner does not share the record and may not have access to the record, depending on his or her privileges. The Organization.ShareRoPreviousOwnerOnAssign attribute controls this setting.
For a list of entities that support Assign, see the AssignRequest.
Retrieving the access rights for a record
Use the RetrievePrincipalAccessRequest message to retrieve the access rights the specified security principal (user or team) has to a record.
Use the RetrieveSharedPrincipalsAndAccessRequest message to retrieves all the security principals (users or teams) that have access to a record, together with their access rights to that record.
Dependencies between access rights
Sometimes, security dependencies exist because it is necessary to have more than one access right to perform a given action. For example, if you have the create access right for accounts, you can create a record of the account entity type. However, unless you also have read access for accounts, you cannot create an account record and be the owner of that new record.
The following table lists the access right dependencies for the actions specified.
Action Access rights required
To Create a record and be the record owner CREATE
READ
To Share a record SHARE. This right is required by the person doing the share operation.
READ. This right is required by the person doing the share operation and also by the person with whom the record is being shared.
To Assign a record ASSIGN
WRITE
READ
To Append To a record READ
APPENDTO
To Append a record READ
APPEND
Another type of dependency exists when objects are subordinate to another object. For example, the opportunity object cannot exist on its own. Each opportunity is always attached to an account or contact. To create an opportunity, you must have the access right appendto on accounts and the access right append on opportunities.
======================================================
Owner Access Team
Owner team or access team?
Choosing the type of the team may depend on the goals, nature of the project, and even the size of your organization. There are a few guidelines that you can use when choosing the team type.
When to use owner teams
Owning records by entities other than users is required by your company’s business policies.
The number of teams is known at the design time of your Microsoft Dynamics 365 system.
Daily reporting on progress by owning teams is required.
When to use access teams
The teams are dynamically formed and dissolved. This typically happens if the clear criteria for defining the teams, such as established territory, product, or volume aren’t provided.
The number of teams isn’t known at the design time of your Microsoft Dynamics 365 system.
The team members require different access rights on the records. You can share a record with several access teams, each team providing different access rights on the record. For example, one team is granted the Read access right on the account and another team, the Read, Write and Share access rights on the same account.
A unique set of users requires access to a single record without having an ownership of the record.
https://msdn.microsoft.com/en-in/library/dn481569.aspx
======================================================
Field Level security
https://www.microsoft.com/en-us/dynamics/crm-customer-center/set-up-security-permissions-for-a-field.aspx
https://msdn.microsoft.com/en-in/library/dn932132.aspx
| Component | Description |
| Business Unit | A scoping mechanism that defines a grouping of users for security modeling purposes; business units are hierarchical in nature. Business Units are a framework upon which a security model is built. |
| Security Role | A collection of privileges (that are given a name) that reflect common user roles of your organization and/or business units; security roles are assigned to users or owner teams. See below for more details on Security Roles. |
| Privilege (access rights) | The definition of a specific type of data access or action that can be granted as a right; privileges are granted through a security role and are cumulative. The following Privileges that can be assigned:
|
| Access Level | While the Privilege defines the type of data access, the Access Level defines exactly to which records the privileges apply. You can assign the Access Levels of:
For example, if you assign Read privileges to a Security Role at the Access Level of “Business Unit”, users with that Security Role will only have the privileges to see records owned by a user within their Business Unit.
|
Access level controls what the user can see(read)/edit
Privilege controls what you can do to the entity.
Privilege controls what you can do to the entity.
Another Example
What we can do to root BU- 1.we cannot rename it, cant delete it .
What we can do to non BU- we cant rename it , disable it
What happens on disabling BU- When a BU is disabled it also disable all sub BU , disable all users, users cant login , do not affect on any data.As soon BU is enabled a user cannot login.
How to Delete BU- First thing is that we cannot delete root BU.To delete child BU first disable the child BU then we can delete it or disable it or reparent it. Re Parent means assigning user to new parent BU. by doing this all previous security role to go out .
Note - We cannot default or root BU but deleting parent BU will delete all child BU so better before deleting reparent the child BU.
Understanding the security roles and BU role in that - One thing we must remember that a user without security role cant login in CRM. So when we create a user it is must to give it atleast one role.User role is also get defined when it is assigned to a team or BU so automatically that user will get the role of Team and it individual role and BU role will be finished off.
Another important point - Dont create security role in root BU because we cannot export it and it will be problem when we export solution .
User can be assigned any security role which exist in its parent BU.
A Good question - What is roles based and object based security in MS CRM ?
Object based security comes into picture when we share a record. It's specific to an entity instance wherein Role based security is for an Entity. In Object based security we use a term called "Access Right" which defines what action(Read, Write, Append, AppendTo, Delete..) that specific user can perform on the shared record. Wherein Role based Security defines what action(Privilige) and at what level(Access Level - User, Org, Parent- Child BU, BU) a user can interact with an entity. If you observe in Object Based Security, we don't talk about "Access Level" as this is specific to a specific entity record. To have an access right on a specific record the user should have "Read" privilige on the entity as part of his Security Role(Role Based Security).
Object-based security in Microsoft Dynamics CRM focuses on how users gain access to individual instances of business objects (entities).
Role-based Security
Role-based security in Microsoft Dynamics CRM is based on the interaction of privileges and access levels, which work together through the use of security roles.
Privileges define what actions a user can perform on each entity in Microsoft Dynamics CRM. Privileges are pre-defined in Microsoft Dynamics CRM and cannot be changed; examples of privileges include Create, Read, Write, and Delete.
Access levels indicate which records associated with each entity the user can perform actions upon.The access level associated with a privilege determines (for a given entity type) the levels within the organizational hierarchy (User, team and Business Unit) at which a user belonging to a specific role can act on that type of entity.
Each security role provides a combination of privileges and access levels specific to a Microsoft Dynamics CRM job function.
Object-based Security
Object-based security applies to individual instances of entities and is provided by using access rights. An access right is granted to a user for a particular entity instance.
The relationship between an access right and a privilege is that access rights apply only after privileges have taken effect. For example, if users do not have the privilege to read accounts, they will be unable to read any account, regardless of the access rights another user might grant them to a specific account through sharing.
Add user in CRM
While adding new user in ms crm we can assign roles.Roles – User
Global Admin – Access to use all the features of ms crm .
Customised Adminstrtor – (Billing admin, Axchange Admin , Password Adminstrator, user management) Total 7
=================================================
Sharing a record
https://msdn.microsoft.com/en-in/library/dn481569.aspx
Record-based security in Microsoft Dynamics 365 and Microsoft Dynamics 365 (online) applies to individual records. It is provided by using access rights.
The relationship between an access right and a privilege is that access rights apply only after privileges have taken effect. For example, if a user does not have the privilege to read accounts, that user is unable to read any account, regardless of the access rights another user might grant to a specific account through sharing.
In This Topic
Access rights
Sharing records
Assigning records
Retrieving the access rights for a record
Dependencies between access rights
Access rights
An access right is granted to a user for a particular record. The following table lists the descriptions for these access rights.
Access right AccessRights enumeration value Description
Read ReadAccess Controls whether the user can read a record.
Write WriteAccess Controls whether the user can update a record.
Assign AssignAccess Controls whether the user can assign a record to another user.
Append AppendAccess Controls whether the user can attach another record to the specified record.
The Append and Append To access rights work in combination. Every time that a user attaches one record to another, the user must have both rights. For example, when you attach a note to a case, you must have the Append access right on the note and the Append To access right on the case for the operation to work.
Append To AppendToAccess Controls whether the user can append the record in question to another record.
The Append and Append To access rights work in combination. For more information, see the description for Append.
Share ShareAccess Controls whether the user can share a record with another user or team. Sharing gives another user access to a record. For more information, see Sharing records.
Delete DeleteAccess Controls whether the user can delete a record.
Create access
The right to create a record for an entity type is not included in the previous table because this right does not apply to an individual record, but instead to a class of entities. Create is handled as a privilege instead of as an access right. The user who creates a record has all rights on that record, unless his or her other privileges forbid a specific right.
The Create privilege controls whether you can create a record. If you have the Create privilege with Local, Deep, or Global access, you can create records for other users. If you have Create and Read privileges with Basic access, you can create records for yourself.
For more information about dependencies that relate to create privileges, see Dependencies between access rights.
Sharing records
Sharing lets users give other users or teams access to specific customer information. This is useful for sharing information with users in roles that have only the Basic access level. For example, in an organization that gives salespeople Basic read and write access to accounts, a salesperson can share an opportunity with another salesperson so that they can both track the progress of an important sale.
For security reasons, develop the practice of sharing only the necessary records with the smallest set of users possible. Only grant the minimum access required for users to do their jobs.
Microsoft Dynamics 365 provides the following sharing capabilities:
• Share. Any user who has share privileges on a given entity type can share records of that type with any other user or team in Microsoft Dynamics 365. To share a record, use GrantAccessRequest.
When you share a record with another user, indicate what access rights (Read, Write, Delete, Append, Assign, and Share) you want to grant to the other user. Access rights on a shared record can be different for each user with whom the record is shared. However, you cannot give a user any rights that he or she would not have for that type of entity, based on the role assigned to that user. For example, if a user does not have Read privileges on accounts and you share an account with that user, the user will be unable to see that account.
• Modify share. You can modify the rights granted to a shared record after it has been shared. To modify sharing for a record, use the ModifyAccessRequest.
• Remove share. If you share a record with another user or team, you can stop sharing the record. After you remove sharing for a record, the other user or team loses access rights to the record. To remove sharing for a record, use the RevokeAccessRequest.
Tip
Use GrantAccessRequest, ModifyAccessRequest, and RevokeAccessRequest for sharing.
A user might have access to the same record in more than one context. For example, a user might share a record directly with specific access rights, and he or she might also be on a team in which the same record is shared with different access rights. In this case, the access rights that this user has on the record are the union of all the rights.
For a list of entities that support sharing, see the GrantAccessRequest.
Sharing and inheritance
If a record is created and the parent record has certain sharing properties, the new record inherits those properties. For example, Joe and Mike are working on a high priority lead. Joe creates a new lead and two activities, shares the lead with Mike, and selects cascade sharing. Mike makes a telephone call and sends an email regarding the new lead. Joe sees that Mike has contacted the company two times, so he does not make another call.
Sharing is maintained on individual records. A record inherits the sharing properties from its parent and also maintains its own sharing properties. Therefore, a record can have two sets of sharing properties—one that it has on its own and one that it inherits from its parent.
Removing the share of a parent record removes the sharing properties of objects (records) that it inherited from the parent. That is, all users who previously had visibility into this record no longer have visibility. Child objects still could be shared to some of these users if they were shared individually, not from the parent record.
Assigning records
Anyone with Assign privileges on a record can assign that record to another user. When a record is assigned, the new user or team becomes the owner of the record and its related records. The original user or team loses ownership of the record, but automatically shares it with the new owner.
In Microsoft Dynamics 365, the system administrator can decide for an organization whether records should be shared with previous owners or not after the assign operation. If Share with previous owner is selected, then the previous owner shares the record with all access rights after the assign operation. Otherwise, the previous owner does not share the record and may not have access to the record, depending on his or her privileges. The Organization.ShareRoPreviousOwnerOnAssign attribute controls this setting.
For a list of entities that support Assign, see the AssignRequest.
Retrieving the access rights for a record
Use the RetrievePrincipalAccessRequest message to retrieve the access rights the specified security principal (user or team) has to a record.
Use the RetrieveSharedPrincipalsAndAccessRequest message to retrieves all the security principals (users or teams) that have access to a record, together with their access rights to that record.
Dependencies between access rights
Sometimes, security dependencies exist because it is necessary to have more than one access right to perform a given action. For example, if you have the create access right for accounts, you can create a record of the account entity type. However, unless you also have read access for accounts, you cannot create an account record and be the owner of that new record.
The following table lists the access right dependencies for the actions specified.
Action Access rights required
To Create a record and be the record owner CREATE
READ
To Share a record SHARE. This right is required by the person doing the share operation.
READ. This right is required by the person doing the share operation and also by the person with whom the record is being shared.
To Assign a record ASSIGN
WRITE
READ
To Append To a record READ
APPENDTO
To Append a record READ
APPEND
Another type of dependency exists when objects are subordinate to another object. For example, the opportunity object cannot exist on its own. Each opportunity is always attached to an account or contact. To create an opportunity, you must have the access right appendto on accounts and the access right append on opportunities.
======================================================
Owner Access Team
Owner team or access team?
Choosing the type of the team may depend on the goals, nature of the project, and even the size of your organization. There are a few guidelines that you can use when choosing the team type.
When to use owner teams
Owning records by entities other than users is required by your company’s business policies.
The number of teams is known at the design time of your Microsoft Dynamics 365 system.
Daily reporting on progress by owning teams is required.
When to use access teams
The teams are dynamically formed and dissolved. This typically happens if the clear criteria for defining the teams, such as established territory, product, or volume aren’t provided.
The number of teams isn’t known at the design time of your Microsoft Dynamics 365 system.
The team members require different access rights on the records. You can share a record with several access teams, each team providing different access rights on the record. For example, one team is granted the Read access right on the account and another team, the Read, Write and Share access rights on the same account.
A unique set of users requires access to a single record without having an ownership of the record.
https://msdn.microsoft.com/en-in/library/dn481569.aspx
======================================================
Field Level security
https://www.microsoft.com/en-us/dynamics/crm-customer-center/set-up-security-permissions-for-a-field.aspx
https://msdn.microsoft.com/en-in/library/dn932132.aspx
Set up security permissions for a field
You can restrict access to a field by creating a field security profile. After you create the profile, you assign users and or teams to that profile, and set up specific read, create, or write permissions for the field.
More information: TechNet: Security concepts for Microsoft Dynamics 365
- Make sure you have the System Administrator security role or equivalent permissions in Microsoft Dynamics 365.
Check your security role - Go to Settings > Security.
- Click Field Security Profiles, and then on the command bar, click New.
- Enter a name and a description (optional) and click Save.
- Under Common, click Field Permissions.
- Select a field, and then click Edit.
- Select the permissions that you want to assign to users or teams, and then click OK.
- To add users or teams:
- Under Members, click Teams or Users.
- On the command bar, click Add.
- In the Look Up Records dialog box, select a team or user from the list (or search for a team or user), and then click Select.
- Repeat the preceding steps to add multiple teams or users, and then click Add.=========================
Thanks for providing such a great information about Dynamics CRM.
ReplyDeleteMicrosoft Dynamics AX Online Training
You are shared valuable information.
ReplyDeleteD365 Finance and Operations Online Training