What is a Windows AD Group?

Grant Nodinite access to whole teams at once. A Windows AD Group in Nodinite is an Active Directory security group mapped to one or more Nodinite Roles. Instead of granting access to individual Users one at a time, you grant access to an entire AD group, and all group members automatically inherit the permissions of the Roles.

• ✅ Automatic provisioning - Users added to the AD group automatically get Nodinite access
• ✅ Centralized management - Control access in Active Directory, not in multiple systems
• ✅ Reduced administrative overhead - Manage 50 users by adding one group instead of 50 individual users
• ✅ Organizational alignment - Access structure mirrors your org chart and team structure
• ✅ Simplified auditing - Review group membership in AD for compliance reporting
• ✅ Faster onboarding - New team members get access by joining existing AD groups

Overview

This approach uses your existing Active Directory infrastructure for centralized Access Management, reducing administrative overhead and keeping access control synchronized with your organizational structure. You manage the groups in the Windows AD Groups Overview.

Domain groups and local groups (a dot as the domain) appear side by side in the list.

Note

Windows Authentication Mode Required

Windows AD Groups are used when your Nodinite environment is configured for Windows Authentication mode. Nodinite supports two authentication modes, chosen in the Auth step when you set up the environment:

• Windows Authentication mode (this page) - Uses Users, Windows AD Groups, and Roles
• OAuth 2.0 / OIDC mode - Uses Claims, Policies, and Roles

If you use OAuth 2.0 / OIDC authentication (Install Nodinite v7 - OpenID), see Claims and Policies instead. To switch modes, see Migrate Authentication Method.

How Windows AD Groups Work

Authentication and Authorization Flow

Blue: the user; purple: Windows infrastructure (IIS and Active Directory); orange: Nodinite authorization; green: the access granted.

1. User logs in to the Nodinite Web Client using Windows credentials
2. IIS authenticates the user against Active Directory (see IIS Authentication settings and NTLM vs Kerberos Authentication)
3. Nodinite queries Windows for the user's group memberships
4. Group-to-Role mapping is evaluated - which Nodinite Roles are assigned to the user's AD groups
5. Permissions are granted based on all Roles assigned to the user's groups (permissions are cumulative)

Example Scenario

Active Directory Setup

• AD Group: CONTOSO\Integration Team (members: Alice, Bob, Charlie)

Nodinite Configuration

• Windows AD Group: CONTOSO\Integration Team
• Assigned to Roles: "Developer" + "Test Environment Access"

Result

• Alice, Bob, and Charlie can all log in to Nodinite
• They automatically have Developer permissions and Test Environment Access
• When David joins the AD group, he immediately gets the same access
• No changes needed in Nodinite

Windows AD Groups vs Individual Users

Understanding when to use each approach helps optimize your access management strategy.

When to Use Windows AD Groups

Choose Windows AD Groups when:

• ✅ You have multiple users with the same access requirements (teams, departments)
• ✅ You want automatic provisioning - users join AD group, they get Nodinite access
• ✅ You prefer centralized management - control access in one place (Active Directory)
• ✅ You need to align access with org structure - mirroring teams, departments, or projects
• ✅ You want to reduce administrative overhead - one group instead of many individual users
• ✅ You use AD group nesting for hierarchical access (e.g., EMEA Team → Finance Team → Finance Admins)

When to Use Individual Users Instead

Choose individual Users (Add or manage User) when:

• ✅ You have external users (partners, vendors, contractors) not in your Active Directory
• ✅ You need fine-grained control over specific individuals
• ✅ The user count is small and doesn't justify creating an AD group
• ✅ You need temporary access not worth creating an AD group for
• ✅ Access requirements are unique to the individual, not shared with others

Mixing Both Approaches

Nodinite allows you to mix Windows AD Groups and individual Users on the same Role.

Example: One Role, Three Assignments

• Role: "Production Monitor"
• Assigned to:
  • Windows AD Group: CONTOSO\Operations Team (20 members)
  • Individual User: PARTNER\john.vendor (external consultant)
  • Individual User: CONTOSO\jane.executive (special access for VP)

Result: All 22 people have Production Monitor access, managed through different mechanisms based on what makes sense for each.

Prerequisites and System Requirements

Infrastructure Requirements

Before using Windows AD Groups in Nodinite, your environment must meet these requirements:

• Windows Server with IIS hosting the Nodinite Web Client and Web API, with Windows Authentication enabled (IIS Authentication settings)
• Server is domain-joined - must be part of the Windows domain or forest
• Domain trusts configured (if accessing groups from other domains/forests)
• Active Directory accessible from the Nodinite server
• Security groups exist in Active Directory (not distribution groups)

System Configuration

Enable Windows AD Groups Feature

Windows AD Groups are enabled by default: the UseActiveDirectoryGroups System Parameter is true. To check or change the setting:

1. Navigate to Administration → Settings → System Parameters
2. Find the UseActiveDirectoryGroups System Parameter
3. Make sure the value is true

The UseActiveDirectoryGroups System Parameter page; select true and click Save to enable Windows AD Groups.

A change takes effect within about 15 seconds; no restart is needed.

Permissions and Access Control

Administrator Role Required

You must be a member of the Nodinite Administrators Role to:

• Add or manage Windows AD Groups
• Assign groups to Roles
• Configure all other administrative objects in Nodinite

The Administrators role is a built-in Role in Nodinite that:

• Cannot be renamed
• Cannot be deleted
• Grants full administrative access
• Is created during initial installation

See Access Management for complete details on the authorization model.

Cumulative Permissions

When a user's AD group is assigned to multiple Roles, they receive all permissions from all Roles (cumulative, not restrictive). What each Role grants is set in its permission sets: Log Views, Monitor Views, Repository Model, and C4 Diagram Sets.

Example: Developer Group in Two Roles

• User is member of AD group CONTOSO\Developers
• CONTOSO\Developers is assigned to:
  • Role: "Test Environment" (access to test Log Views)
  • Role: "Repository Contributor" (access to Repository Model)
• User gets: Test Log Views + Repository Model access (combined permissions)

Limitations and Important Notes

Built-in Windows Administrators Group

The built-in Windows Administrators group cannot be added to Nodinite as a Windows AD Group. This is a security restriction to prevent unintended administrative access.

Workaround: Create a dedicated AD group for Nodinite administrators (e.g., CONTOSO\Nodinite Admins) instead of using the built-in Windows Administrators group.

No Automatic Name Validation

Nodinite does not validate whether the Windows AD Group name you enter actually exists in Active Directory.

What This Means

• Spelling matters - Ensure the group name is spelled exactly as it appears in AD
• Format matters - Must use DOMAIN\GroupName format (backslash, not forward slash)
• Case sensitivity - May be case-sensitive depending on your AD configuration
• Manual verification required - Test by having a group member log in

Best practice: Copy the exact group name from Active Directory (via PowerShell Get-ADGroup or AD Users and Computers) to avoid typos.

Group Renames Require Manual Updates

If someone renames a Windows AD Group in Active Directory:

• Nodinite continues referencing the old name
• Users will lose access until the name is updated in Nodinite
• No automatic synchronization occurs
• Nodinite Administrator must manually update the group name in Nodinite

Recommendation: Coordinate with your Active Directory administrators to be notified of group renames affecting Nodinite access.

Security Groups Only (Not Distribution Groups)

Only Active Directory Security Groups work with Nodinite. Distribution groups (used for email) are not supported for authentication purposes.

Verify group type in PowerShell:

Get-ADGroup -Identity "Integration Team" | Select-Object Name, GroupCategory
# GroupCategory should be "Security", not "Distribution"

Common Scenarios

Scenario 1: Department-Based Access

Situation: Finance department needs access to SAP integration logs

Solution: Reuse the Finance Group

1. Use existing AD group CONTOSO\Finance Team (or create if doesn't exist)
2. In Nodinite, add Windows AD Group CONTOSO\Finance Team
3. Assign to Role "Finance Log Access" (configured with SAP Log Views)
4. All Finance team members automatically get access

Benefits: When finance hires new staff, they join the AD group and automatically get Nodinite access.

Scenario 2: Multi-Tier Support Team

Situation: L1 support needs monitoring access, L2 support needs logs + monitoring, L3 needs full access

Solution: One Group per Support Tier

1. Create AD groups: CONTOSO\Support L1, CONTOSO\Support L2, CONTOSO\Support L3
2. Add all three as Windows AD Groups in Nodinite
3. Assign to Roles:
   • L1 → "Production Monitors" (Monitor Views)
   • L2 → "Production Monitors" + "Production Logs"
   • L3 → "Production Monitors" + "Production Logs" + "Repository Model" + Remote Actions
4. Users get appropriate access based on their support tier

Benefits: Support team structure in Nodinite mirrors organizational support levels.

Scenario 3: Project-Based Temporary Access

Situation: 12-person project team needs access to Project Phoenix integration logs for 6 months

Solution: A Temporary Project Group

1. IT creates temporary AD group CONTOSO\Project Phoenix
2. Add as Windows AD Group in Nodinite with description "Project Phoenix team - ends June 2026"
3. Assign to Role "Project Phoenix Logs"
4. When project ends, IT deletes AD group (or removes Nodinite configuration)

Benefits: Clean separation of project access, easy to grant and revoke for entire team at once.

Next Steps

Ready to add Windows AD Groups to Nodinite?

• Add or manage Windows AD Group – Step-by-step guide to adding and configuring groups
• View All Windows AD Groups – Manage your existing Windows AD Groups
• Add or manage Role – Create the Roles to assign to groups
• Permission Set for Log Views – Grant access to log data
• Permission Set for Monitor Views – Grant monitoring dashboard access
• Permission Set for the Repository Model – Grant integration documentation access
• Permission Set for C4 Diagram Sets – Grant access to C4 Diagram Sets

Related Topics

Access Management

• Access Management – Main access control overview
• Roles – Understanding role-based permissions
• Users – Individual user management (alternative or complement to groups)
• Access Management Troubleshooting – Solutions to common access problems

System Configuration

• System Parameters – System-wide configuration settings
• UseActiveDirectoryGroups – Enable/disable Windows AD Groups feature
• IIS Authentication settings – Windows Authentication in IIS
• NTLM vs Kerberos Authentication – Choose and troubleshoot the Windows protocol
• Auth step in the Portal – Choose the authentication mode
• Web Client – Nodinite user interface
• Web API – Nodinite API access

Features

• Log Views – Log data viewing and filtering
• Monitor Views – Real-time monitoring dashboards
• Log Audits – Track user activity and access

Alternative Authentication Modes

• Claims – OIDC/OAuth 2.0 authorization (alternative to Windows AD Groups)
• Policies – OIDC/OAuth 2.0 Policy management
• Migrate Authentication Method – Switch between Windows and OIDC/OAuth 2.0