Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
---
description: >
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.
keywords:
- 500 error
- Okta SSO
- SHA1
- SHA256
- RSA_SHA256
- internal server error
- published reports
- Netwrix Access Analyzer
- OWIN
- SAML
products:
- access-analyzer
sidebar_label: '500 Internal Server Error When Using Okta SSO for Published Reports'
title: '500 Internal Server Error When Using Okta SSO for Published Reports'
knowledge_article_id: ka0Qk000000G55NIAS
---

# 500 Internal Server Error When Using Okta SSO for Published Reports

## Related Queries

- "Receiving 500 error after login using Okta."
- "Published Reports site fails with Okta."
- "NAA SAML SSO broken."

## Symptom

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:

```text
500 Internal Server Error
```

## Cause

The Okta application is configured to use the **SHA1** algorithm for signing SAML assertions.

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.

## Resolution

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.

1. In Okta, navigate to the **Application** used for Published Reports.
2. Open the **General Settings** tab.
3. Scroll to the **Signature Algorithm** section.
![Okta Application Settings page showing the Signature Algorithm section with SHA1 selected](/docs/kb/accessanalyzer/images/kA0Qk00000036C9KAI-Okta-settings.jpg)
4. Set the following:
- **Signature Algorithm**: `RSA_SHA256`
- **Digest Algorithm**: `SHA256`
5. Save the changes.

> **NOTE:** After saving, users may need to sign out and back in for the new settings to take effect.
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
---
description: >
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.
keywords:
- Exchange Online
- EWSMAILBOX
- certificate warning
- private key
- CertificateAuthority
- certmgr.msc
- Intermediate Certification Authorities
- Personal store
- thumbprint
- Netwrix Access Analyzer
products:
- access-analyzer
sidebar_label: 'Exchange Online Certificate Warning for Private Key in CertificateAuthority Store'
title: 'Exchange Online Certificate Warning for Private Key in CertificateAuthority Store'
knowledge_article_id: ka0Qk000000G8WHIA0
---

# Exchange Online Certificate Warning for Private Key in CertificateAuthority Store

## Symptom

You see the following warning after running any jobs using the `EWSMAILBOX` data collector to collect data from Exchange Online:

```text
WARNING | Matching cert: '{Certificate Thumbprint}' in location: CurrentUser store: CertificateAuthority does not have private key.
```

## Cause

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.

1. The certificate (including the private key) is correctly installed in the **Personal** (My) store.
2. A *duplicate* public key-only version of the same certificate is also present in the **Intermediate Certification Authorities** (`CertificateAuthority`) store.
3. When code searches certificate stores, it encounters the `CertificateAuthority` version first—but it lacks the private key.
4. A warning is logged before continuing to the correct version in the **Personal** store, which contains the private key.

## Resolution

To resolve the warning, follow these steps:

1. Open **`certmgr.msc`**.
2. In the **Personal > Certificates** store, verify that the certificate with the specified thumbprint exists *and includes a private key*.

> **NOTE:** You can confirm this by opening the certificate and checking for the message:
> `You have a private key that corresponds to this certificate.`
3. Once confirmed, navigate to the **Intermediate Certification Authorities > Certificates** store.
4. Locate the *duplicate* certificate with the same thumbprint.
5. Confirm that this version *does not* contain a private key.
6. Delete the duplicate certificate from the Intermediate Certification Authorities store.

> **IMPORTANT:** Always confirm that the valid certificate with the private key exists in the **Personal** store *before* removing the duplicate from the `CertificateAuthority`.
100 changes: 100 additions & 0 deletions docs/kb/accessanalyzer/FileSystem-Permissions-Format-Reference.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,100 @@
---
description: >
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.
keywords:
- filesystem permissions
- FSAA
- Netwrix Access Analyzer
- allowrightsdescription
- denyrightsdescription
- L R W D M A
- permission strings
- SQL bitwise
- effective permissions
- access control
products:
- access-analyzer
sidebar_label: 'FileSystem Permissions Format Reference'
title: 'FileSystem Permissions Format Reference'
knowledge_article_id: ka0Qk000000G6ZJIA0
---

# FileSystem Permissions Format Reference

## Related Queries

- "What does LRWDMA mean in FSAA?"
- "What does the 'A' permission stand for in Netwrix Access Analyzer?"
- "Why are there letters like L, R, W in permission strings?"

## Overview

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.

## Instructions

### Permission Letter Definitions

Each letter in the permission string corresponds to a specific type of access:

| Letter | Name | Bit Value | Description |
|--------|------|------------|-------------|
| L | List | 32 (0x20) | List folder contents or traverse folder paths |
| R | Read | 1 (0x01) | Read data from files or list contents of a folder |
| W | Write | 2 (0x02) | Write data to files or create files and folders |
| D | Delete | 4 (0x04) | Delete files and folders |
| M | Manage | 8 (0x08) | Modify permissions or change ownership |
| A | Admin | 16 (0x10) | Full administrative control, including ownership rights |

> **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.

### Example Permission Strings

| String | Meaning |
|---------|----------|
| `LRWDMA` | Full Control |
| `LRWD` | Modify (no admin rights) |
| `LRW` | Standard user access |
| `LR` | Read-only access |
| `L` | Traverse only |
| `RW` | Read and write without list |
| `A` | Admin-only |
| `(empty)` | No permissions |

### Views That Use This Format

The letter-based permission format is used in the following database views:

- `SA_FSAA_ExpandedPermissionsView` — Includes both direct and inherited effective permissions.
- `SA_FSAA_DirectPermissionsView` — Directly assigned permissions only.
- `SA_FSAA_InheritedPermissionsView` — Permissions inherited from parent folders.
- `SA_FSAA_PermissionsView` — Combined view of direct and inherited permissions.
- `SA_FSAA_EffectiveAccessView` — Effective permissions on shared resources.

### Related Columns in Views

In addition to `AllowRightsDescription` and `DenyRightsDescription`, the permission views also include:

- Boolean columns: `AllowList`, `AllowRead`, `AllowWrite`, etc.
- Raw bitmask columns: `AllowRights`, `DenyRights`
- Windows-style descriptions: `AllowMaskDescription`, `DenyMaskDescription`

### Technical Details

The permission strings are generated using SQL bitwise logic. For example:

```sql
(CASE WHEN (p.AllowRights & 32) <> 0 THEN 'L' ELSE '' END) +
(CASE WHEN (p.AllowRights & 1) <> 0 THEN 'R' ELSE '' END) +
(CASE WHEN (p.AllowRights & 2) <> 0 THEN 'W' ELSE '' END) +
(CASE WHEN (p.AllowRights & 4) <> 0 THEN 'D' ELSE '' END) +
(CASE WHEN (p.AllowRights & 8) <> 0 THEN 'M' ELSE '' END) +
(CASE WHEN (p.AllowRights & 16) <> 0 THEN 'A' ELSE '' END) AS AllowRightsDescription
```

### Important Usage Notes

- **Deny overrides allow**: If both Allow and Deny include the same letter, the permission is denied.
- **Empty string means no rights**: No access is granted if the string is blank.
- **Always in order**: Letters appear in the standard order (`L-R-W-D-M-A`) when present.
- **Effective access**: Use the expanded view to see the final calculated result after inheritance is resolved.
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
---
description: >
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.
keywords:
- SharePoint permissions
- SPAA
- Netwrix Access Analyzer
- AllowRights
- DenyRights
- RWDM
- SPBasePermissions
- GenericRights
- 4-bit model
- effective permissions
products:
- access-analyzer
sidebar_label: 'SharePoint Permissions Format Reference'
title: 'SharePoint Permissions Format Reference'
knowledge_article_id: ka0Qk000000G6cXIAS
---

# SharePoint Permissions Format Reference

## Related Queries

- "What does `AllowRights = 15` mean in SharePoint permissions?"
- "What does RWDM represent in SPAA?"
- "How are SharePoint permissions simplified in Netwrix Access Analyzer?"

## Overview

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)**.

This article explains what those letters mean, how the bitmask values are calculated, and where they appear in the SPAA interface.

## Instructions

### Permission Letter Definitions

Each right corresponds to a specific bit value and represents a simplified category of SharePoint permissions:

| Letter | Name | Decimal Value | Description |
|--------|------|----------------|--------------|
| R | Read | 1 | View items, pages, versions, and user profile info |
| W | Write | 2 | Add or edit list items, documents, and web content |
| D | Delete | 4 | Delete items, past versions, or cancel checkouts |
| M | Manage | 8 | Approve items, manage lists, permissions, or alerts |

> **NOTE:** These letters are always ordered as **R-W-D-M**, and combined additively. A value of `0` (or empty string) means no permissions.

### Common Permission Values

| Decimal | String | Meaning |
|----------|---------|----------|
| 0 | (empty) | No rights granted |
| 1 | R | Read only |
| 3 | RW | Read + Write |
| 7 | RWD | Read + Write + Delete |
| 8 | M | Manage only |
| 9 | RM | Read + Manage |
| 15 | RWDM | Full rights (all four permissions) |

### How Rights Are Calculated

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:

- If the base permissions include *any* rights associated with reading (e.g., `ViewListItems`, `Open`, `ViewVersions`), the **Read** bit is set.
- If write-related permissions are present (e.g., `AddListItems`, `EditListItems`, `ManageLists`), the **Write** bit is set.
- If deletion capabilities are found (e.g., `DeleteListItems`, `DeleteVersions`), the **Delete** bit is set.
- If *any* administration permissions are found (e.g., `ManagePermissions`, `ManageWeb`, `ApproveItems`), the **Manage** bit is set.

Each enabled bit is summed to produce a decimal value between 0 and 15.

### Where This Format Appears

The SPAA `RWDM` format is used in the following database views:

- `SA_SPAA_EffectiveAccessView`
- `SA_SPAA_PermissionsView`
- `SA_SPAA_DirectPermissionsView`
- `SA_SPAA_InheritedPermissionsView`

You may also see these supporting columns:

- `AllowRightsDescription`, `DenyRightsDescription` — Human-readable letter strings
- `AllowRead`, `AllowWrite`, `AllowDelete`, `AllowManage` — Boolean flags
- `AllowRights`, `DenyRights` — Raw numeric rights (0–15)

### Key Considerations

- **Deny takes precedence**: If a right exists in both Allow and Deny, access is denied.
- **Order is consistent**: Always shown as R-W-D-M.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.