A: No. All permissions are read-only. The application can:

• ✅ Read user information
• ✅ Read group memberships
• ❌ Cannot create, modify, or delete users in Azure AD
• ❌ Cannot modify groups or directory objects
• ❌ Cannot change passwords or security settings

The application only reads data from Azure AD. Any user management in Azure AD must be done by your Azure AD administrators.

A: The application stores:

• User profile information (name, email, job title) in Ideagen Visitor Management System (Ideagen VMS)'s database
• Group memberships synced from Azure AD
• User roles and permissions assigned based on group membership

Data is stored in Ideagen Visitor Management System (Ideagen VMS)'s database, not in Azure AD. Your organization's data is isolated from other organizations using Ideagen Visitor Management System (Ideagen VMS) (multi-tenant architecture).

A: No. The permissions granted only allow access to:

• User directory information (profiles, groups)
• Directory structure

The application cannot access:

• ❌ Email (Exchange Online)
• ❌ Files (OneDrive, SharePoint)
• ❌ Calendar
• ❌ Teams
• ❌ Any other Microsoft 365 services

A: You can revoke consent at any time:

1. Go to Azure Portal → Enterprise Applications
2. Find the Ideagen Visitor Management System (Ideagen VMS) application
3. Go to Permissions
4. Click "Revoke admin consent"

Effects of revoking:

• Users will no longer be able to use SSO login
• The application will lose access to Azure AD data
• Existing users in Ideagen Visitor Management System (Ideagen VMS) will remain, but new logins via SSO will fail

A: No. Admin consent is granted once for your entire organization. After you grant admin consent:

• All users in your organization can use SSO
• The application can read user and group information for all users
• No individual user consent is required

A: Yes, this is secure when following Microsoft's best practices:

Security measures:

• ✅Read-only permissions - cannot modify your Azure AD
• ✅Application permissions - more secure than user-delegated permissions
• ✅Admin consent required - ensures proper oversight
• ✅Multi-tenant isolation - your data is separate from other organizations
• ✅Microsoft's security standards - follows Microsoft's recommended practices

Risks are minimal:

• The application can only read data, not modify it
• Your Azure AD administrators maintain full control
• You can revoke consent at any time
• Data is stored securely in Ideagen Visitor Management System (Ideagen VMS)'s database with tenant isolation

A: The application requires these specific permissions for its functionality:

• User.Read.All: Needed to read user profiles and create accounts automatically
• Group.Read.All: Critical - needed to read group memberships for automatic role assignment

Why not just User.Read?

• User.Read only allows reading the signed-in user's own profile
• The application needs to read all users' profiles for admin dashboards and user management

Why User.Read.All + Group.Read.All are sufficient:

• ✅ According to latest Azure documentation, User.Read.All CAN efficiently perform filtered queries like GET /users?$filter=accountEnabled eq false
• ✅ User.Read.All + Group.Read.All are sufficient for all current functionality

According to latest Azure documentation, User.Read.All supports filtered queries on the /users endpoint.

A: Before granting consent, verify:

1. Application name: Should be "Ideagen Visitor Management System (Ideagen VMS)" or "VMS SSO Application"
2. Publisher: Check with your organization's IT department or the person who requested this
3. Client ID: Verify the Client ID matches what was provided by your organization
4. Permissions requested: Should match the required permissions listed in this guide (User.Read.All + Group.Read.All are required)

If in doubt, contact your organization's IT department or the person who requested admin consent.

A: If you have security concerns or questions:

1. Contact your organization's IT department - they can verify the request
2. Review Microsoft's documentation - links provided throughout this guide
3. Contact Ideagen Visitor Management System (Ideagen VMS) support - if provided by your organization
4. Review the permissions - all are read-only and follow Microsoft's best practices

A: Yes. You can monitor the application's API calls through Azure AD audit logs:

1. Azure Portal → Azure Active Directory → Monitoring → Sign-in logs
   • Filter by:
     • Application: Ideagen Visitor Management System (Ideagen VMS) / VMS SSO Application
     • Service principal: The service principal created when consent was granted
2. Azure Portal → Azure Active Directory → Monitoring → Audit logs
   • Filter by Service principal to see all API calls

What you'll see:

• When API calls were made
• Which endpoints were accessed (e.g., /users, /groups)
• Success/failure status
• IP addresses (if available)

Note: Microsoft Graph API calls may appear in audit logs with some delay. For real-time monitoring, consider using Azure AD Conditional Access policies or Microsoft Sentinel.

Reference: Azure AD Audit Logs

A: This is a valid security concern. Here's what you should know:

If credentials are compromised:

1. The attacker would have the same read-only access as the application
2. They could read user profiles and group memberships
3. They could NOT modify, delete, or create anything in Azure AD
4. They could NOT access email, files, or other Microsoft 365 data

Mitigation steps you can take:

1. Revoke admin consent immediately if you suspect compromise:
   • Azure Portal → Enterprise Applications → Ideagen Visitor Management System (Ideagen VMS) → Permissions → Revoke admin consent
2. Monitor audit logs for suspicious activity
3. Contact Ideagen Visitor Management System (Ideagen VMS) support to report the incident
4. Require credential rotation - ask Ideagen Visitor Management System (Ideagen VMS) to rotate their Client Secret

Best practices Ideagen Visitor Management System (Ideagen VMS) should follow:

• ✅ Store Client Secret securely (Azure Key Vault, environment variables)
• ✅ Rotate Client Secrets regularly (recommended: every 90 days)
• ✅ Use certificate-based authentication (more secure than secrets)
• ✅ Monitor for credential compromise
• ✅ Implement proper access controls and logging

You can also:

• Set up Conditional Access policies to restrict where the application can authenticate from
• Use IP restrictions if Ideagen Visitor Management System (Ideagen VMS) provides their IP ranges
• Monitor unusual sign-in patterns in Azure AD logs

A: Partially. With Application Permissions, you have limited control:

What you CAN do:

1. Conditional Access Policies: You can create Conditional Access policies that apply to the service principal, but this mainly affects authentication, not data access
2. Administrative Units: If your organization uses Administrative Units, the application can only access users/groups within the scope of the permissions granted
3. Revoke consent: You can revoke consent entirely if needed

What you CANNOT do:

• ❌ Cannot restrict Application Permissions to specific users or groups
• ❌ Cannot use scoped permissions (Application Permissions are tenant-wide)
• ❌ Cannot limit which users the application can read

Why:

Application Permissions are designed for service-to-service operations where the application needs broad access. Microsoft's security model assumes that if you grant Application Permissions, you trust the application with tenant-wide read access.

Alternative approach:

If you need granular control, you could:

1. Use Delegated Permissions instead (but this requires each user to consent)
2. Implement custom logic in your Azure AD to restrict which users are visible
3. Use Administrative Units to limit the scope of directory operations

Reference: Conditional Access for Service Principals

A: The application queries Azure AD in the following scenarios:

On-demand queries (user-initiated):

• User login: When a user logs in via SSO, the application queries:
  • User profile information (1 API call)
  • User's group memberships (1 API call)
  Frequency: Only when users log in

Scheduled/background operations:

• Admin user sync: Typically runs on a schedule (e.g., daily, weekly) or on-demand
  • Queries all users to identify admin users
  • Frequency: As configured by your organization
• Inactive user cleanup: Typically runs periodically
  • Queries disabled users
  • Frequency: As configured by your organization

API call patterns:

• Bulk operations: Uses efficient queries (e.g., GET /users?$filter=...) rather than individual queries
• Rate limiting: The application respects Microsoft Graph API rate limits
• Throttling: If rate limits are hit, the application will retry with exponential backoff

Typical usage:

• Low volume: For most organizations, API calls are infrequent (only during logins and scheduled syncs)
• High volume organizations: May see more frequent calls, but still within Microsoft's rate limits

You can monitor this:

• Check Azure AD audit logs to see actual API call frequency
• Request API usage reports from Ideagen Visitor Management System (Ideagen VMS) if needed

Reference: Microsoft Graph Throttling Guidance

A: This is a valid security concern. Here's the reality:

What the application CAN do:

• ✅ Read user profiles (name, email, job title, department)
• ✅ Read group memberships
• ✅ Read directory structure
• ✅ Store this data in Ideagen Visitor Management System (Ideagen VMS)'s database

What this means:

• Yes, the application can read and store your directory data
• Yes, this data is stored outside your Azure AD (in Ideagen Visitor Management System (Ideagen VMS)'s database)
• This is necessary for the application to function (user accounts, role assignment, etc.)

Security considerations:

1. Data is stored in Ideagen Visitor Management System (Ideagen VMS)'s database - you're trusting Ideagen Visitor Management System (Ideagen VMS) with your data
2. Multi-tenant isolation - your data should be isolated from other organizations
3. Access controls - Ideagen Visitor Management System (Ideagen VMS) should have proper access controls on their database
4. Encryption - data should be encrypted at rest and in transit

What you can do:

1. Review Ideagen Visitor Management System (Ideagen VMS)'s security practices - ask about:
   • Database security
   • Access controls
   • Encryption
   • Data isolation
2. Request a security assessment or SOC 2 report
3. Monitor audit logs to see what data is being accessed
4. Use Conditional Access to restrict where the application can authenticate from

Risk assessment:

• Low risk: If Ideagen Visitor Management System (Ideagen VMS) is a trusted vendor with proper security practices
• Medium risk: If you have concerns about their security posture
• Mitigation: Request security documentation, audits, or assessments

Recommendation: Treat this like any other SaaS application - ensure Ideagen Visitor Management System (Ideagen VMS) has proper security controls and data protection measures in place.

A: Yes, with limitations. Here's what you can do:

What you CAN do:

1. Service Principal Conditional Access:
   • Create Conditional Access policies that apply to the service principal
   • Restrict authentication to specific IP addresses (if Ideagen Visitor Management System (Ideagen VMS) provides IP ranges)
   • Require specific locations or conditions
2. Authentication restrictions:
   • Restrict where the application can authenticate from
   • Require specific network locations
   • Block authentication from certain countries/regions

What you CANNOT do:

• ❌ Cannot restrict which users the application can read (Application Permissions are tenant-wide)
• ❌ Cannot use user-based Conditional Access policies (Application Permissions don't involve user context)
• ❌ Cannot restrict data access based on user attributes

How to set it up:

1. Azure Portal → Azure Active Directory → Security → Conditional Access
2. Create a new policy
3. Assignments → Service Principals → Select the Ideagen Visitor Management System (Ideagen VMS) service principal
4. Conditions: Set your restrictions (IP addresses, locations, etc.)
5. Access controls: Grant or block access

Limitations:

• Conditional Access mainly affects authentication, not data access
• Once authenticated, the application can read data based on the permissions granted
• You're primarily restricting where the application can authenticate from, not what it can access

Reference: Conditional Access for Service Principals

A: This is an excellent technical question. Here's the key difference:

Delegated Permissions:

• User context: Acts on behalf of a signed-in user
• User consent: Each user must consent (or admin consent for all users)
• Scope: Limited to what the signed-in user can access
• Use case: User-initiated actions (e.g., "read my profile")
• Limitation: Requires a user to be signed in

Application Permissions:

• App context: Acts as the application itself (no user signed in)
• Admin consent: Only admin consent required (one-time)
• Scope: Tenant-wide access (based on permissions granted)
• Use case: Background operations, service-to-service operations
• Advantage: Can operate without a user being signed in

Why Ideagen Visitor Management System (Ideagen VMS) uses Application Permissions:

1. Background operations: Needs to sync users, check account status, etc. without user interaction
2. Efficiency: Can perform bulk operations without requiring each user to be signed in
3. User lifecycle management: Can detect disabled users and remove them automatically
4. Admin user sync: Can sync administrative users without them being signed in

Why not Delegated Permissions:

• ❌ Cannot perform background operations (requires user to be signed in)
• ❌ Cannot sync admin users automatically
• ❌ Cannot detect and remove inactive users
• ❌ Limited scope: Only works for signed-in users
• ❌ Inefficient: Would require each user to consent and be signed in

Security comparison:

• Application Permissions: More powerful but more secure when properly managed (admin consent, read-only)
• Delegated Permissions: Less powerful but requires user context

Microsoft's recommendation: Use Application Permissions for service-to-service operations and background tasks, which is exactly what Ideagen Visitor Management System (Ideagen VMS) needs.

Reference: Delegated vs Application Permissions

A: Yes, with some limitations. Here's how to monitor:

Real-time monitoring options:

1. Azure AD Sign-in Logs:
   • Azure Portal → Azure Active Directory → Monitoring → Sign-in logs
   • Filter by Application or Service Principal
   • Shows authentication attempts in near real-time
2. Azure AD Audit Logs:
   • Azure Portal → Azure Active Directory → Monitoring → Audit logs
   • Filter by Service Principal
   • Shows API calls and operations
   • Note: May have a delay (typically 15-30 minutes)
3. Microsoft Graph Activity Logs (if available):
   • More detailed API call information
   • Requires appropriate permissions to view

Advanced monitoring:

1. Microsoft Sentinel (if you have it):
   • Real-time monitoring and alerting
   • Custom queries and dashboards
   • Alert rules for suspicious activity
2. Azure Monitor:
   • Custom alerts based on audit log queries
   • Dashboard creation
   • Integration with other monitoring tools

What you'll see:

• ✅ Authentication attempts (when the app authenticates)
• ✅ API calls (which endpoints were accessed)
• ✅ Success/failure status
• ✅ Timestamps
• ⚠️ Limited detail: May not show exact data accessed (for privacy/security)

Limitations:

• Audit logs may have a delay (not truly "real-time")
• Some API calls may be batched or aggregated
• Detailed data access logs may be limited for privacy reasons

Recommendation: Set up alerts for unusual activity (e.g., authentication from unexpected locations, high API call volumes).

A: Excellent security practice! Here's how to do it:

Option 1: Use a test Azure AD tenant

1. Create or use a test Azure AD tenant
2. Grant admin consent in the test tenant first
3. Test SSO functionality
4. Verify API calls in audit logs
5. Once satisfied, grant consent in production tenant

Option 2: Use a pilot group

1. Grant admin consent in production
2. Enable SSO for a small pilot group first
3. Monitor usage and API calls
4. Gradually roll out to more users
5. Revoke consent if issues are found

What to test:

• ✅ SSO login works correctly
• ✅ User accounts are created properly
• ✅ Group memberships sync correctly
• ✅ Roles are assigned based on groups
• ✅ Audit logs show expected API calls
• ✅ No unexpected data access

Questions to ask Ideagen Visitor Management System (Ideagen VMS):

1. Do you support staging/test environments?
2. Can we use a test tenant for validation?
3. What's your recommended testing approach?

Best practice: Always test in a non-production environment first when possible.

A: You control this. Here's how it works:

Current permissions:

• The permissions you grant are fixed at the time of consent
• The application cannot automatically add new permissions

If new permissions are needed:

1. Ideagen Visitor Management System (Ideagen VMS) must request new permissions
2. You must grant admin consent again for the new permissions
3. You'll see a new consent screen with the additional permissions
4. You can review and decide whether to grant them

How to monitor:

1. Azure Portal → Enterprise Applications → Ideagen Visitor Management System (Ideagen VMS) → Permissions
2. Check the permissions list regularly
3. Set up alerts for permission changes (if supported)

What you can do:

1. Require notification: Ask Ideagen Visitor Management System (Ideagen VMS) to notify you before requesting new permissions
2. Review requests: Always review new permission requests carefully
3. Document baseline: Document the current permissions for comparison
4. Regular audits: Periodically review the permissions granted

Best practice: Include in your agreement with Ideagen Visitor Management System (Ideagen VMS) that they must notify you before requesting additional permissions.

A: Service Principal is the Azure AD representation of the application in your tenant:

What it is:

• An identity for the application in your Azure AD
• Created automatically when you grant admin consent
• Represents the Ideagen Visitor Management System (Ideagen VMS) application in your tenant

What it can do:

• ✅ Authenticate using Client ID and Secret
• ✅Access Microsoft Graph API based on permissions granted
• ✅ Read data according to the permissions you granted
• ❌ Cannot modify anything (read-only permissions)
• ❌ Cannot access other services (only what permissions allow)

Where to find it:

1. Azure Portal → Azure Active Directory → Enterprise Applications
2. Find "Ideagen Visitor Management System (Ideagen VMS)" application
3. The Object ID is the service principal ID

What you can do with it:

• Monitor: See its activity in audit logs
• Restrict: Apply Conditional Access policies
• Revoke: Remove admin consent to disable it
• Audit: Review what permissions it has

Security considerations:

• The service principal uses Client Credentials flow (app-only authentication)
• It authenticates using Client ID + Client Secret (stored by Ideagen Visitor Management System (Ideagen VMS))
• It operates independently of any user being signed in

Reference: Service Principals in Azure AD

A:Yes, through Azure AD audit logs. Here's how:

How to access:

1. Azure Portal → Azure Active Directory → Monitoring → Audit logs
2. Filter by:
   • Service Principal: Select the Ideagen Visitor Management System (Ideagen VMS) service principal
   • Date range: Select your desired time period
   • Activity: Filter by specific activities if needed

What you'll see:

• ✅ Timestamp: When the API call was made
• ✅ Service Principal: The application that made the call
• ✅ Activity: What operation was performed (e.g., "Read user", "Read group")
• ✅ Target: What resource was accessed
• ✅ Status: Success or failure
• ⚠️ Limited detail: May not show exact data returned (for privacy)

Export options:

1. Download as CSV: Export audit logs for analysis
2. PowerShell: Use Get-AzureADAuditDirectoryLogs cmdlet
3. Microsoft Graph API: Query audit logs programmatically
4. Microsoft Sentinel: Advanced querying and analysis

Limitations:

• Audit logs are retained for a limited time (typically 30-90 days, depending on your license)
• Some detailed information may be redacted for privacy
• Very high-volume operations may be aggregated

Questions to ask Ideagen Visitor Management System (Ideagen VMS):

1. Can you provide API usage reports?
2. Do you log API calls on your side?
3. Can you provide access logs if requested?

Reference: Azure AD Audit Logs