What is a Windows AD Group?

Overview

A Windows AD Group in Nodinite is an Active Directory security group mapped to one or more Nodinite Roles to enable team-based access control. Instead of granting access to individual user accounts one at a time, you can grant access to an entire AD group, and all group members automatically inherit the assigned permissions.

This approach leverages your existing Active Directory infrastructure for centralized access management, reducing administrative overhead and ensuring access control stays synchronized with your organizational structure.

Example of the list of defined Windows AD Groups in Nodinite.

Why Use Windows AD Groups?

Windows AD Groups offer several advantages for enterprise environments:

• ✅ Automatic provisioning - Users added to 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

How Windows AD Groups Work

Authentication and Authorization Flow

1. User logs in to Nodinite using Windows credentials
2. IIS authenticates the user against Active Directory
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.

Factor	Windows AD Groups	Individual Users
Best for	Teams, departments, roles with many members	External users, special cases, fine-grained control
Management location	Active Directory (centralized)	Nodinite (application-specific)
Provisioning speed	Automatic when user joins AD group	Manual - must add each user individually
Typical use case	10+ users with similar permissions	Partners, vendors, unique access requirements
Maintenance effort	Low - managed in AD	Higher - managed per user in Nodinite
Access revocation	Remove from AD group (immediate)	Must remove from Nodinite manually
Audit trail	AD group membership reports	Nodinite user list
Flexibility	Group-level permissions	Per-user permissions
Organizational sync	Automatic - reflects AD structure	Manual - must mirror org changes

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 leverage AD group nesting for hierarchical access (e.g., EMEA Team → Finance Team → Finance Admins)

When to Use Individual Users Instead

Choose individual Users 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:

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

Note

Windows Authentication Mode Required

This page documents Windows AD Groups, which are used when your Nodinite environment is configured for Windows Authentication mode.

Nodinite supports two authentication modes (chosen during environment setup):

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

If you are using OAuth 2.0 / OIDC authentication, see Claims and Policies instead of this page.

Prerequisites and System Requirements

Infrastructure Requirements

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

• Windows Server with IIS hosting Nodinite
• 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 not enabled by default. To activate this feature:

1. Navigate to Administration → Settings → System Parameters
2. Find the UseActiveDirectoryGroups system parameter
3. Set the value to true
4. Recycle the IIS Application Pools for both Web Client and Web API
5. Clear browser cache (Ctrl+F5 or Ctrl+R)

Example of the 'UseActiveDirectoryGroups' system parameter set to true.

Important

After enabling this feature, you must recycle the IIS Application Pools for the changes to take effect. Simply saving the parameter is not sufficient.

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

Example:

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

Important implications:

• 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:

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:

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"
   • 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:

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.

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

---

Next Step

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

Once groups are configured, set up permissions:

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

Related Topics

Access Management

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

Windows AD Groups Management

Add or manage Windows AD Group – How to add and configure groups
View All Windows AD Groups – Overview of all configured groups

Permission Configuration

Permission Set for Log Views – Configure Log View access
Permission Set for Monitor Views – Configure Monitor View access
Permission Set for the Repository Model – Configure Repository Model access

System Configuration

System Parameters – System-wide configuration settings
UseActiveDirectoryGroups – Enable/disable Windows AD Groups feature
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