Skip to content

Commit dd16031

Browse files
hilram7hilram7
authored
Merge pull request #335 from netwrix/NAA-KB-NEW
Add Access Analyzer KB Articles
2 parents f5e0dca + 2f6b5f1 commit dd16031

5 files changed

+304
-0
lines changed

‎docs/kb/accessanalyzer/500-Internal-Server-Error-Using-Okta-SSO-Published-Reports.md‎

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
---
2+
description: >
3+
Users encounter a 500 Internal Server Error when accessing the Netwrix Access Analyzer Published Reports site using Okta Single Sign-On (SSO). The issue occurs because the Okta application uses the SHA1 algorithm, which is not supported by modern .NET Framework and OWIN security libraries.
4+
keywords:
5+
- 500 error
6+
- Okta SSO
7+
- SHA1
8+
- SHA256
9+
- RSA_SHA256
10+
- internal server error
11+
- published reports
12+
- Netwrix Access Analyzer
13+
- OWIN
14+
- SAML
15+
products:
16+
- access-analyzer
17+
sidebar_label: '500 Internal Server Error When Using Okta SSO for Published Reports'
18+
title: '500 Internal Server Error When Using Okta SSO for Published Reports'
19+
knowledge_article_id: ka0Qk000000G55NIAS
20+
---
21+
22+
# 500 Internal Server Error When Using Okta SSO for Published Reports
23+
24+
## Related Queries
25+
26+
- "Receiving 500 error after login using Okta."
27+
- "Published Reports site fails with Okta."
28+
- "NAA SAML SSO broken."
29+
30+
## Symptom
31+
32+
When attempting to connect to the Netwrix Access Analyzer (formerly Enterprise Auditor) Published Reports site using Okta Single Sign-On (SSO), users encounter the following error message:
33+
34+
```text
35+
500 Internal Server Error
36+
```
37+
38+
## Cause
39+
40+
The Okta application is configured to use the **SHA1** algorithm for signing SAML assertions.
41+
42+
The modern .NET Framework (4.6.2 and later) and OWIN-based security libraries reject SHA1, as it is deprecated. These platforms require a more secure algorithm, such as **SHA256**, for WS-Federation and SAML tokens.
43+
44+
## Resolution
45+
46+
To resolve this issue, update the signature and digest algorithms in the Okta application settings. These changes ensure compatibility with the security expectations of modern .NET/OWIN libraries used by the Published Reports site.
47+
48+
1. In Okta, navigate to the **Application** used for Published Reports.
49+
2. Open the **General Settings** tab.
50+
3. Scroll to the **Signature Algorithm** section.
51+
![Okta Application Settings page showing the Signature Algorithm section with SHA1 selected](/docs/kb/accessanalyzer/images/kA0Qk00000036C9KAI-Okta-settings.jpg)
52+
4. Set the following:
53+
- **Signature Algorithm**: `RSA_SHA256`
54+
- **Digest Algorithm**: `SHA256`
55+
5. Save the changes.
56+
57+
> **NOTE:** After saving, users may need to sign out and back in for the new settings to take effect.

‎docs/kb/accessanalyzer/Exchange-Online-Certificate-Warning-Private-Key-CertificateAuthority-Store.md‎

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
---
2+
description: >
3+
Explains the cause and resolution for the "Matching cert does not have private key" warning that appears when running the EWSMAILBOX data collector in Netwrix Access Analyzer for Exchange Online. Includes steps to locate and remove duplicate certificates.
4+
keywords:
5+
- Exchange Online
6+
- EWSMAILBOX
7+
- certificate warning
8+
- private key
9+
- CertificateAuthority
10+
- certmgr.msc
11+
- Intermediate Certification Authorities
12+
- Personal store
13+
- thumbprint
14+
- Netwrix Access Analyzer
15+
products:
16+
- access-analyzer
17+
sidebar_label: 'Exchange Online Certificate Warning for Private Key in CertificateAuthority Store'
18+
title: 'Exchange Online Certificate Warning for Private Key in CertificateAuthority Store'
19+
knowledge_article_id: ka0Qk000000G8WHIA0
20+
---
21+
22+
# Exchange Online Certificate Warning for Private Key in CertificateAuthority Store
23+
24+
## Symptom
25+
26+
You see the following warning after running any jobs using the `EWSMAILBOX` data collector to collect data from Exchange Online:
27+
28+
```text
29+
WARNING | Matching cert: '{Certificate Thumbprint}' in location: CurrentUser store: CertificateAuthority does not have private key.
30+
```
31+
32+
## Cause
33+
34+
This warning typically occurs because certificates are stored in different locations on the system. Below is an example of why this warning may appear, depending on the certificate configuration.
35+
36+
1. The certificate (including the private key) is correctly installed in the **Personal** (My) store.
37+
2. A *duplicate* public key-only version of the same certificate is also present in the **Intermediate Certification Authorities** (`CertificateAuthority`) store.
38+
3. When code searches certificate stores, it encounters the `CertificateAuthority` version first—but it lacks the private key.
39+
4. A warning is logged before continuing to the correct version in the **Personal** store, which contains the private key.
40+
41+
## Resolution
42+
43+
To resolve the warning, follow these steps:
44+
45+
1. Open **`certmgr.msc`**.
46+
2. In the **Personal > Certificates** store, verify that the certificate with the specified thumbprint exists *and includes a private key*.
47+
48+
> **NOTE:** You can confirm this by opening the certificate and checking for the message:
49+
> `You have a private key that corresponds to this certificate.`
50+
3. Once confirmed, navigate to the **Intermediate Certification Authorities > Certificates** store.
51+
4. Locate the *duplicate* certificate with the same thumbprint.
52+
5. Confirm that this version *does not* contain a private key.
53+
6. Delete the duplicate certificate from the Intermediate Certification Authorities store.
54+
55+
> **IMPORTANT:** Always confirm that the valid certificate with the private key exists in the **Personal** store *before* removing the duplicate from the `CertificateAuthority`.

‎docs/kb/accessanalyzer/FileSystem-Permissions-Format-Reference.md‎

Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
---
2+
description: >
3+
Reference guide for interpreting the compact letter-based permission format used in Netwrix Access Analyzer FileSystem Access Auditing (FSAA). Includes definitions for each permission letter, example strings, related database views, and SQL logic details.
4+
keywords:
5+
- filesystem permissions
6+
- FSAA
7+
- Netwrix Access Analyzer
8+
- allowrightsdescription
9+
- denyrightsdescription
10+
- L R W D M A
11+
- permission strings
12+
- SQL bitwise
13+
- effective permissions
14+
- access control
15+
products:
16+
- access-analyzer
17+
sidebar_label: 'FileSystem Permissions Format Reference'
18+
title: 'FileSystem Permissions Format Reference'
19+
knowledge_article_id: ka0Qk000000G6ZJIA0
20+
---
21+
22+
# FileSystem Permissions Format Reference
23+
24+
## Related Queries
25+
26+
- "What does LRWDMA mean in FSAA?"
27+
- "What does the 'A' permission stand for in Netwrix Access Analyzer?"
28+
- "Why are there letters like L, R, W in permission strings?"
29+
30+
## Overview
31+
32+
The Netwrix Access Analyzer (formerly Enterprise Auditor) for FSAA (FileSystem Access Auditing) permission views include columns called `AllowRightsDescription` and `DenyRightsDescription`, which use a **compact letter-based format** to represent access rights to files and folders. This article explains what each letter means, how to read the permission strings, and where these codes are used.
33+
34+
## Instructions
35+
36+
### Permission Letter Definitions
37+
38+
Each letter in the permission string corresponds to a specific type of access:
39+
40+
| Letter | Name | Bit Value | Description |
41+
|--------|------|------------|-------------|
42+
| L | List | 32 (0x20) | List folder contents or traverse folder paths |
43+
| R | Read | 1 (0x01) | Read data from files or list contents of a folder |
44+
| W | Write | 2 (0x02) | Write data to files or create files and folders |
45+
| D | Delete | 4 (0x04) | Delete files and folders |
46+
| M | Manage | 8 (0x08) | Modify permissions or change ownership |
47+
| A | Admin | 16 (0x10) | Full administrative control, including ownership rights |
48+
49+
> **NOTE:** Permission strings are formed by combining the letters in the order `L-R-W-D-M-A`. An empty string means no permissions are granted.
50+
51+
### Example Permission Strings
52+
53+
| String | Meaning |
54+
|---------|----------|
55+
| `LRWDMA` | Full Control |
56+
| `LRWD` | Modify (no admin rights) |
57+
| `LRW` | Standard user access |
58+
| `LR` | Read-only access |
59+
| `L` | Traverse only |
60+
| `RW` | Read and write without list |
61+
| `A` | Admin-only |
62+
| `(empty)` | No permissions |
63+
64+
### Views That Use This Format
65+
66+
The letter-based permission format is used in the following database views:
67+
68+
- `SA_FSAA_ExpandedPermissionsView` — Includes both direct and inherited effective permissions.
69+
- `SA_FSAA_DirectPermissionsView` — Directly assigned permissions only.
70+
- `SA_FSAA_InheritedPermissionsView` — Permissions inherited from parent folders.
71+
- `SA_FSAA_PermissionsView` — Combined view of direct and inherited permissions.
72+
- `SA_FSAA_EffectiveAccessView` — Effective permissions on shared resources.
73+
74+
### Related Columns in Views
75+
76+
In addition to `AllowRightsDescription` and `DenyRightsDescription`, the permission views also include:
77+
78+
- Boolean columns: `AllowList`, `AllowRead`, `AllowWrite`, etc.
79+
- Raw bitmask columns: `AllowRights`, `DenyRights`
80+
- Windows-style descriptions: `AllowMaskDescription`, `DenyMaskDescription`
81+
82+
### Technical Details
83+
84+
The permission strings are generated using SQL bitwise logic. For example:
85+
86+
```sql
87+
(CASE WHEN (p.AllowRights & 32) <> 0 THEN 'L' ELSE '' END) +
88+
(CASE WHEN (p.AllowRights & 1) <> 0 THEN 'R' ELSE '' END) +
89+
(CASE WHEN (p.AllowRights & 2) <> 0 THEN 'W' ELSE '' END) +
90+
(CASE WHEN (p.AllowRights & 4) <> 0 THEN 'D' ELSE '' END) +
91+
(CASE WHEN (p.AllowRights & 8) <> 0 THEN 'M' ELSE '' END) +
92+
(CASE WHEN (p.AllowRights & 16) <> 0 THEN 'A' ELSE '' END) AS AllowRightsDescription
93+
```
94+
95+
### Important Usage Notes
96+
97+
- **Deny overrides allow**: If both Allow and Deny include the same letter, the permission is denied.
98+
- **Empty string means no rights**: No access is granted if the string is blank.
99+
- **Always in order**: Letters appear in the standard order (`L-R-W-D-M-A`) when present.
100+
- **Effective access**: Use the expanded view to see the final calculated result after inheritance is resolved.

‎docs/kb/accessanalyzer/SharePoint-Permissions-Format-Reference.md‎

Lines changed: 92 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
---
2+
description: >
3+
Explains how Netwrix Access Analyzer represents SharePoint permissions using the simplified 4-bit model (R, W, D, M). Includes definitions, value mapping, and examples of where the format appears in SPAA database views.
4+
keywords:
5+
- SharePoint permissions
6+
- SPAA
7+
- Netwrix Access Analyzer
8+
- AllowRights
9+
- DenyRights
10+
- RWDM
11+
- SPBasePermissions
12+
- GenericRights
13+
- 4-bit model
14+
- effective permissions
15+
products:
16+
- access-analyzer
17+
sidebar_label: 'SharePoint Permissions Format Reference'
18+
title: 'SharePoint Permissions Format Reference'
19+
knowledge_article_id: ka0Qk000000G6cXIAS
20+
---
21+
22+
# SharePoint Permissions Format Reference
23+
24+
## Related Queries
25+
26+
- "What does `AllowRights = 15` mean in SharePoint permissions?"
27+
- "What does RWDM represent in SPAA?"
28+
- "How are SharePoint permissions simplified in Netwrix Access Analyzer?"
29+
30+
## Overview
31+
32+
In Netwrix Access Analyzer (formerly Enterprise Auditor) for SharePoint Access Auditing (SPAA), the `AllowRights` and `DenyRights` columns use numeric values to represent simplified access rights. These values are based on SharePoint’s `SPBasePermissions` enumeration and mapped to a 4-bit model that includes **Read (R), Write (W), Delete (D), and Manage (M)**.
33+
34+
This article explains what those letters mean, how the bitmask values are calculated, and where they appear in the SPAA interface.
35+
36+
## Instructions
37+
38+
### Permission Letter Definitions
39+
40+
Each right corresponds to a specific bit value and represents a simplified category of SharePoint permissions:
41+
42+
| Letter | Name | Decimal Value | Description |
43+
|--------|------|----------------|--------------|
44+
| R | Read | 1 | View items, pages, versions, and user profile info |
45+
| W | Write | 2 | Add or edit list items, documents, and web content |
46+
| D | Delete | 4 | Delete items, past versions, or cancel checkouts |
47+
| M | Manage | 8 | Approve items, manage lists, permissions, or alerts |
48+
49+
> **NOTE:** These letters are always ordered as **R-W-D-M**, and combined additively. A value of `0` (or empty string) means no permissions.
50+
51+
### Common Permission Values
52+
53+
| Decimal | String | Meaning |
54+
|----------|---------|----------|
55+
| 0 | (empty) | No rights granted |
56+
| 1 | R | Read only |
57+
| 3 | RW | Read + Write |
58+
| 7 | RWD | Read + Write + Delete |
59+
| 8 | M | Manage only |
60+
| 9 | RM | Read + Manage |
61+
| 15 | RWDM | Full rights (all four permissions) |
62+
63+
### How Rights Are Calculated
64+
65+
SPAA evaluates SharePoint’s full `SPBasePermissions` bitmask (a 64-bit `ulong` value) and translates it into the simplified 4-bit `GenericRights` model using internal logic like the following:
66+
67+
- If the base permissions include *any* rights associated with reading (e.g., `ViewListItems`, `Open`, `ViewVersions`), the **Read** bit is set.
68+
- If write-related permissions are present (e.g., `AddListItems`, `EditListItems`, `ManageLists`), the **Write** bit is set.
69+
- If deletion capabilities are found (e.g., `DeleteListItems`, `DeleteVersions`), the **Delete** bit is set.
70+
- If *any* administration permissions are found (e.g., `ManagePermissions`, `ManageWeb`, `ApproveItems`), the **Manage** bit is set.
71+
72+
Each enabled bit is summed to produce a decimal value between 0 and 15.
73+
74+
### Where This Format Appears
75+
76+
The SPAA `RWDM` format is used in the following database views:
77+
78+
- `SA_SPAA_EffectiveAccessView`
79+
- `SA_SPAA_PermissionsView`
80+
- `SA_SPAA_DirectPermissionsView`
81+
- `SA_SPAA_InheritedPermissionsView`
82+
83+
You may also see these supporting columns:
84+
85+
- `AllowRightsDescription`, `DenyRightsDescription` — Human-readable letter strings
86+
- `AllowRead`, `AllowWrite`, `AllowDelete`, `AllowManage` — Boolean flags
87+
- `AllowRights`, `DenyRights` — Raw numeric rights (0–15)
88+
89+
### Key Considerations
90+
91+
- **Deny takes precedence**: If a right exists in both Allow and Deny, access is denied.
92+
- **Order is consistent**: Always shown as R-W-D-M.

‎docs/kb/accessanalyzer/images/kA0Qk00000036C9KAI-Okta-settings.jpg‎

44.1 KB
Loading

0 commit comments

Comments
 (0)