Folgendes Szenario:
Ihr bekommt einen Access-Error im CRM. Ihr ladet die Log-Datei runter und habt dann ungefähr folgende Infos:
CrmException:
SecLib: AccessCheckEx failed. Returned hr = -2147187962,
ObjectID: abe86dd6-d7aa-e311-ade6-cfcd73da4a68,
OwnerId: db2f6110-1a9d-df11-9d85-005056bb728e,
OwnerIdType: 8 and
CallingUser: edce293b-789d-e311-950c-ed9561bb126a.
ObjectTypeCode: 4201,
objectBusinessUnitId: 966fe7c8-89c1-de11-853f-005056bb728e,
AccessRights: 262153
Jaaaa. Wo genau ist denn jetzt der Fehler? AccessRight 262153 ist da nicht wirklich hilfreich.
Die Seite http://dotnetdust.blogspot.co.uk/2014/03/how-to-interpret-accessrights-numbers.html ist mir von einem MS-Supporti empfohlen worden (klingt komisch, ist aber so).
Die wandeln das AccessRight erst in binär um (einfach nach "262153 in binary" googlen) und vergleichen dann mit der dort angegebenen Tabelle.
| Name |
Value |
Binary Value |
Description |
| ReadAccess |
1 |
0001 |
Specifies the right to read the specified type of object. |
| WriteAccess |
2 |
0010 |
Specifies the right to update (write to) the specified object. |
| AppendAccess |
4 |
0100 |
Specifies the right to append the specified object to another object. |
| AppendToAccess |
16 |
0001 0000 |
Specifies the right to append another object to the specified object. |
| CreateAccess |
32 |
0010 0000 |
Specifies the right to create an instance of the object type. |
| DeleteAccess |
65536 |
0001 0000 0000 0000 0000 |
Specifies the right to delete the specified object. |
| ShareAccess |
262144 |
0100 0000 0000 0000 0000 |
Specifies the right to share the specified object. |
| AssignAccess |
524288 |
1000 0000 0000 0000 0000 |
Specifies the right to assign the specified object to another security principal. |
262153 -> 0100 0000 0000 0000 1001
Also ist der Fehler hier im ReadAccess (0001) und im ShareAccess (0100 0000 0000 0000 0000) zu finden.
1000 ist zum Teil das Gleiche wie 0001 0000, also auch noch AppendTo.
