CRM 2013 – MB2-703 – Security Exam Cram Notes

This blog contains the study notes for the MB2-703 – CRM 2013 Customization and configuration exam and for the area of Security.

Security covers a lot of topics and is worth 10-15 percent of the final exam marks, so you definitely need to know the functionality and limitations of security.

I have gone through the separate parts of security in the blogs below and there are videos going through these which you can find on the youtube playlist

All the study notes for the MB2-703 exam can be found on the page link above or clicking the link below

https://crmbusiness.wordpress.com/mb2-703-crm-2013-customization-and-configuration-certification/

These notes are the to revise the key concepts of security for the MB2-703 – Microsoft Dynamics CRM 2013 Customization and Configuration certification

There is a video going through the list below with some explanation

Business Units and Security Roles

• When a business unit is disabled the users in that business unit cannot access CRM
• users of a disabled business unit will still consume a CRM Licence
• child business unit users will also not be able to access CRM
• the records of a disabled business unit user are not disabled.
• To delete a business unit you must remove all child business units and any users or teams linked to the business unit
• To delete a business unit you must disable it first
• Each business unit has a default team of the same name
• you cannot add users to a default business unit team
• you cannot delete a default business unit team
• Equipment/Facilities and Resource Groups do not need to be removed before you can delete a business unit
• business units can have separate security roles, even with the same name!
• Disabling a business unit (and child business units) will mean all the users in that business unit won’t be able to login to CRM.
• moving business units is done by changing the business units parent
• The Root business unit is a default business unit which has the same name as the organisation.
• You cannot delete the Root business unit, you cannot disable it
• You cannot create a business unit above the Root business unit, e.g. you cannot give it a parent.
• Business units are used to create a hierarchy and this is in a tree structure.  The Root business unit will be at the top.
• none of the data is affected by disabling business units, its only the users who cannot then log in but it is important to take into account all the child business units will also be disabled.  This only applies to inherited roles. Roles that are created in a BU explicitly will move with it
• The users are not disabled but cannot login into CRM whilst the business unit is disabled.  As soon as the business unit is enabled they will be able to log into CRM again.
• if you want to delete the business unit then you will need to change all the users/teams that are assigned to that business unit.  You also need to disable the business unit before you delete it.
• You cannot delete the default business unit team but it won’t stop you deleting the business unit because this will be deleting automatically when you delete the business unit.
• When you disable a business unit, it disables all child business unit.  The users in these business units will not be able to login
• When you change the parent of a business unit, it removes and rebuilds all the security roles of the inherited security from the parent business unit.  So all the users in the business unit will have no security roles and they will not be able to login
• Users can login if they are part of a team which has security roles.  They won’t be able to set any personal options.
• You can change the Name of a business unit.
• You Can change the name of the root business unit.

Security Roles and Teams

• if a user doesn’t have a security role he cannot access the system, so every user must have at least one security role.
• Security roles are linked with the user business unit to calculate what records the user can access.
• Users receive their permissions to work on records or use features based on the combination of Security Roles they are assigned and the Business Units to which the users belong.
• Security roles can also be assigned to teams and if the team a user is a member of has higher security privileges then this will override their individual security roles.  The user will also use the highest security levels it is assigned, whether that’s from a security roles assigned to the team or individual security role
• Users can be assigned multiple security roles, this means it’s possible to create security roles just for single purposes.
• There are 15 default security roles in CRM
•  The default security roles are all created in the root business unit.
• A security role stays in the business unit it is created in and they copy down to any child business units.
•  if you create a security role in the root business unit then the security role will be copied to all the child business units below it.
• User can be assigned any security role which exist in their business unit.
• only security roles which exist in the root business unit can be added to a solution file.
• it’s quicker to modify existing security roles than create new ones
• All security roles are the same except the System Administrator role which is a super role.
• The System Administrator role automatically has access to all records and entities, including all custom entities.  It has the default access level of organisation for all privileges.
• At least One user must have the System Administrator role, this is by default given to the user who installed CRM
• Multiple users can be assigned the System Administrator role and you can remove the role from users but you cannot remove the role if that user is the only user who has the System Administrator role.
• The System Administrator role also is given the System Admin field level security role, which as I’m sure you can guess gives them access to all field level security.
• It’s possible to copy the System Administrator role and it will create a security role but the security role will not automatically have access to any new custom entities added and it basically won’t have the special powers of the System Administrator role.
• Teams have security roles (this can affect which form is used)
• There are some privileges which do not have organisation levels these are always show under miscellaneous privileges and these are either true or false.  These are things like

Go Offline

Export to Excel

Publish articles

 

Manage user access, Teams and sharing

• The security authentication in CRM is not really handled inside CRM.  A bit like the way CRM lets outlook/email router do all the emailing, CRM also gets another piece of software to do the authentication of users.
• the most common authentication method is active directory
• You can also used Internet facing deployment (IFD) where the authentication is either AD FS (active Directory Federation Services) or STS (Secure Token service)
• Online security – Microsoft Online Subscription Program (MSOP)
• A user can have one manager which is a user lookup field on user record

Functionality to manage users and you can find these by going to Settings – Administration

• Creating users, teams, Security Roles
• assign/move users to teams, assign security roles to teams and users
• Disable business units
• Delete Security roles, Delete teams
• Move users between teams
• Manager

Users

• You cannot delete users in CRM you can only disable them
• If you disable a user the user won’t be able to log into CRM
• a disabled user doesn’t use a CRM license
• The records assigned to the user are still active.  Best practice is to assign all the records assigned to the disable user to another enabled user.
• You need to work out if the user is used in the workings of any workflows, these will still work but it’s not good practice to assign records etc to an disabled user.
• Users must always be assigned to business unit and can only be assigned to one business.
• Security roles and teams security roles are additive, so adding a user to a team won’t remove any security privileges to the user

Teams

• Teams are optional
• Two types of teams Access teams and owner teams
• Owner Team can own records
• Owner Teams can be assigned security roles
• Access teams cannot own be assigned security roles or own records.
• An owner team can be converted to an access team
• An access team cannot be converted to an owner team
• Each business unit create a default team which you cannot delete and you cannot add members to
• Teams can be assigned security roles
• Team and users can be the owner of records

 

Business units and default owner teams

• Business units have a team created automatically, the team name will have the same name as the business unit.  Any members created and assigned to the business unit will automatically be added to the default business unit team.
• It’s a dynamic team which CRM keeps up to date.
• It cannot be edited but you can assign security roles and these security roles will apply to all members of the business unit.
• default business unit team cannot be re parented, deleted or renamed and it’s members cannot be modified.

SHARING

• In CRM you can share records between users and teams.  Sharing gives the user being shared to the same privileges to that individual record as the user who is sharing.
• Sharing bypasses business unit – access level parts of security because when you share records it basically ignore the level (organisation, business unit, user)
• Sharing records to a team is like sharing the record with every member of the team, except in the PrincipalObjectTable this is only one entry
• using the business unit default team you can share records to all users in different business units.
• You can share more than records, you can also share Charts, Views and Dashboards.
• Users can only share their personal views, charts and dashboards.
• When a user shares the components (charts, views and dashboards) they also choose what privileges you want the user/team to have with the component

The privileges you can share are

Read

Write

Delete

Append

Assign

Share

 

Re-parenting users/teams

•  Re-parenting a user/teams business unit has a drastic effect on the security roles the user or team had, it REMOVES THEM ALL.
•  So if you ever change a user/teams business unit you will need to assign the user or team some security roles in the new business unit.
• This sounds drastic but it actually makes sense if you think about it logically.  Each business unit has it’s own set of security roles, these are usually copied down from the parent business units.  So when you move business unit, it removes all the security roles and it can’t automatically add them all back because not all the security roles may exist in the new business unit or the security roles could be vastly different with completely different privileges, so the user must add new security roles.
• This is also true if you re-parent a whole business unit because all the users will have had all their security roles removed.
• Remember users without security roles cannot log into CRM.
• If a user is re-parented they lose their security roles but they won’t be removed from any teams, this would probably allow them to login to CRM but the user won’t be able to change any personal settings, or view any components the user created.
• If a team is re-parented then every member of team will lose all their security roles because the team will have had all it’s security roles removed.
• An efficiency trick is if you want to remove all the security roles for a user or team is to move business unit

 

AUDITING

• Auditing has three levels – Global, Entity, Field
• Auditing is enabled in System settings and then for each individual entity
• Any entity can be audited
• if auditing is not enabled at organisational level, it doesn’t matter if auditing is turned on at an entity level, nothing will be audited.
• audit logs are partitioned every 3 months.  These can be  deleted in the audit log management screen
• User has to have the View Audit History privilege
• when you turn on auditing for an entity, all the available fields are by default enabled for auditing
• Audit logs management is done by a system job
• Some System fields are not applicable for auditing

CreatedOn
CreatedBy
ModifiedOn
ModifiedBy
Owning Business Unit
Owning User
Customer AddressId

 

Access Teams and Access Team Templates

•  Access teams are new functionality added in CRM 2013 (so expect some questions)
• Access Teams and Access team templates are a method to share permissions and records, which is easier to manage, quicker to add/remove users/teams because Access team templates will applying a standard set of privileges (read, write, delete, append, append to) rather than having to set this up for each individual user/team.
• Access Team templates are enabled on an entity basis and you have to enable Access Teams on the entity in the communications and collaboration section
• Access teams can be ticked and un ticked on an entity (unlike Queues)
• You need to customize the form of the entity you want to add the Access Team Template to and in my case it’s the account form
• You need to add a sub grid to the form
• Records – All TypesEntity – UsersDefault View – Associated Record Team MembersTeam Template – Hosk Account Access Team – this is the team template I created in the step before, yours is probably called something different.
• When you add a user to the user grid it will automatically create an Access Team but the odd things is you can’t view this team in the Teams section in Administration
• You can view access teams by using the advanced find, search for Teams and choose of type Access.
• You add users to the access team via the sub grid on the record.
• you can add users directly to the access team.

• You can more than one Access Team template for each entity
• The default number of access teams templates for each entity is two
• The number of access team templates you can have for each entity is controlled by theMaxAutoCreatedAccessTeamsPerEntity deployment setting.
• MaxEntitiesEnabledForAutoCreatedAccessTeams deployment setting has a default value of 5.  This controls the number of entities it’s possible to enable for auto-created access teams.
• You can change the MaxEntitiesEnabledForAutoCreatedAccessTeams , MaxAutoCreatedAccessTeamsPerEntity  only on Premise installations and you cannot edit them for Online.
• A system generated Access Team isn’t created for each record until you add a user to the sub grid on the entity.
• if you delete the team, this is the same removing all the members in the sub grid on the record.
• if you change the access rights on Team Template this will only change the access right to new entity records/access teams.  Any records already created will use the previous set of privileges.
• Access teams with Share access right ticked will mean any user who is in access team will be able to add (share) others to the access team for that record.
• Users cannot grant privileges they do not have.  So a user can only add new members to an access team where the access team template has delete privilege only if that user has the delete privilege for the entity.
• Access Teams created automatically by adding users to them are not shown in the system team views
• If you want to delete a Access Team Template you will need to remove all the sub grids using that specific Access Team Template before you can delete it.

 

Owner Team

• Owner teams in Microsoft Dynamics CRM can have security roles
• Team can own records

Access Team

• Access teams cannot be granted security roles
• Access teams cannot own records
• Accesses records through sharing
• Sharing privileges are defined by an access team template but don’t change dynamically for existing records if the template changes
• Access teams are not displayed in most system views
• You can add/remove users directly on the subgrid of the record you want to share access to.

 

Field Level security

• Enabling or disabling of field level security by setting the IsSecured attribute cannot be audited.
• System Admin is has all privileges on all field level security fields, the user has a System Administrator field security profile where all values are set to yes and will be for any fields checked for field level security.
• Every field enabled for field level security is added to all field level security profiles
• when you turn on field level security for a field, it will automatically be added to all Field Level security roles with Read, Create and Update all set to No.
• New field level security fields can only be seen by users with the System Administrator role, so you have to go and configure the field level security privileges.
• Every field level security profile will include all fields with field level security enabled.
• Fields that are ticked for field level security will be added to field security profiles but with Read, Update, Create all set to No, so you must go in to configure
• users/teams can be added to more than one field level security profile.
• *** asterisks show if a user does not have read access to a field
• *** asterisks show even if the field is null/blank
• You cannot delete the System Administrator field level security profile
• You can only set field level security on custom fields!