Category: Azure

Azure

  • Mastering PRT Delayed Renewal in Microsoft Entra ID: Controls, Configurations, and Real-World Scenarios

    Mastering PRT Delayed Renewal in Microsoft Entra ID: Controls, Configurations, and Real-World Scenarios

    In the evolving landscape of identity management, the Primary Refresh Token (PRT) stands as a cornerstone of seamless single sign-on (SSO) in Microsoft Entra ID. As devices increasingly operate in hybrid environments—online, offline, or in hibernation—understanding how to control PRT delayed renewal is essential for security admins and architects. Delayed renewal refers to the postponement of PRT updates during periods of disconnection, allowing cached SSO while balancing risk.

    This technical deep-dive explores PRT mechanics, indirect control mechanisms (since direct timeline tweaks aren’t available), working configuration examples, expanded scenarios, and practical tips. We’ll leverage tables for clarity and draw from official Microsoft documentation to ensure accuracy as of late 2025. Whether you’re enforcing stricter security in a high-risk sector or optimizing for user experience, these insights will help you fine-tune PRT behavior.

    PRT Renewal Mechanics: The Foundation

    A PRT is a device-bound artifact enabling SSO across Entra-integrated apps on platforms like Windows, iOS, macOS, and Android. It’s issued during device registration or join and includes claims for user identity, device compliance, and more.

    Key Timelines

    • Validity Period: 90 days, with continuous renewal during active use.
    • Renewal Interval: Every 4 hours via the CloudAP plugin during Windows sign-in. For apps, the Web Account Manager (WAM) plugin renews PRTs under conditions like silent token requests without a refresh token or when the PRT is invalid (e.g., requiring MFA).
    • Delayed Renewal: If offline (e.g., due to network disconnect or hibernation), renewal pauses until reconnection and a qualifying event (e.g., sign-in or app token request). Cached PRTs remain usable for SSO up to the 90-day limit.
    • Offline Handling: No immediate termination; PRTs support offline SSO, but renewal requires internet for CloudAP or WAM checks.

    These intervals (4 hours, 90 days) are fixed and non-configurable directly, as per Microsoft’s design for consistency. However, policies can indirectly cap effective lifetimes by forcing re-authentication on reconnect.

    Table 1: PRT Renewal Triggers and Conditions

    Trigger TypeDescriptionInterval/ConditionOffline Impact
    CloudAP PluginRenews during Windows sign-in.Every 4 hoursDelayed until reconnect + sign-in
    WAM PluginRenews via app token requests (silent or interactive).On-demand (e.g., invalid PRT)Delayed; cached PRT used until reconnect
    Inactivity ExpiryPRT expires if unused.After 90 daysFull expiry; re-auth required
    Event-BasedPassword change or revocation invalidates PRT.Immediate on detectionCached until reconnect, then invalidated

    Control Mechanisms: Indirect Ways to Influence Delayed Renewal

    While you can’t adjust the 4-hour or 90-day windows, Entra ID offers policy-based levers to enforce re-evaluations on reconnect, effectively shortening offline PRT usability. Below, we detail each mechanism with additional nuances, configuration steps, and working examples.

    1. Sign-in Frequency (SIF) in Conditional Access

    SIF mandates re-authentication intervals, overriding PRT defaults by requiring fresh auth for renewal. It accounts for a 5-minute clock skew to avoid over-prompting.

    • Additional Details: SIF doesn’t evaluate during PRT issuance but impacts app-driven renewals (e.g., via WAM). In offline scenarios, it triggers on reconnect, potentially blocking renewal if unsatisfied.
    • Configuration Example (Entra Admin Center):
    1. Navigate to Entra ID > Security > Conditional Access > New Policy.
    2. Name: “High-Security SIF”.
    3. Users: Select groups (e.g., executives).
    4. Cloud Apps: All or specific (e.g., Exchange Online).
    5. Session > Sign-in Frequency: Set to “1 hour” or “Every time”.
    6. Enable in report-only mode first.
    • PowerShell Working Example (Using Microsoft Graph SDK):
      # Install if needed: Install-Module Microsoft.Graph
      Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
      $params = @{
          DisplayName = "SIF Policy - 1 Hour"
          State = "enabledForReportingButNotEnforced"
          Conditions = @{
              Applications = @{ IncludeApplications = "All" }
              Users = @{ IncludeUsers = "All" }
          }
          SessionControls = @{
              SignInFrequency = @{
                  Value = 1
                  Type = "hours"
              }
          }
      }
      New-MgIdentityConditionalAccessPolicy -BodyParameter $params
    • Impact: Reduces offline window; e.g., a 1-hour SIF means re-auth on reconnect after >1 hour offline.

    2. Token Protection

    Binds PRTs cryptographically to devices (via TPM), preventing replay. It validates binding during renewal, invalidating unbound PRTs.

    • Additional Details: Supports Windows 10+ and specific apps (e.g., OneDrive 22.217+). Errors like AADSTS1002 (no device state) or 1006 (unsupported OS) trigger on unbound renewals. In hibernation, TPM failures can invalidate PRTs post-wake.
    • Configuration Example:
    1. Entra Admin Center: Conditional Access > New Policy.
    2. Target: Office 365 apps.
    3. Conditions: Windows platforms.
    4. Session > Require Token Protection: Enable.
    5. Test in report-only; monitor logs for tokenProtectionStatusDetails.
    • Working Log Query Example (Log Analytics):
      SigninLogs
      | where TimeGenerated > ago(7d)
      | where ConditionalAccessPolicies has "Require token protection"
      | summarize Count=count() by tokenProtectionStatusDetails, signInSessionStatusCode
    • Impact: Ensures delayed renewal only succeeds on the bound device; mismatches force re-auth.

    3. Continuous Access Evaluation (CAE)

    CAE enables real-time revocation via events (e.g., account disable) or policies (e.g., IP changes), extending tokens to 28 hours while allowing instant invalidation.

    • Additional Details: Uses claim challenges (401 errors) for revocation. In offline reconnects, CAE checks sync’ed policies; supports apps like Outlook/Teams.
    • Configuration Example:
    1. Entra Admin Center: Conditional Access > Customize CAE.
    2. Enable for IP/location policies.
    3. Define trusted IPs: Add IPv4/IPv6 ranges.
    • Working Scenario Simulation: Use “What If” tool to test a user reconnecting from an untrusted IP—CAE issues challenge, revoking PRT.
    • Impact: Overrides delayed renewal; e.g., if risk detected offline, revocation applies on reconnect.

    4. Device Compliance Policies

    Integrates with Intune; PRTs carry compliance claims, failing renewal if non-compliant on reconnect.

    • Additional Details: Checks OS version, encryption, etc. Non-compliance (e.g., post-hibernation patch miss) blocks renewal.
    • Configuration Example (Intune):
    1. Intune > Devices > Compliance Policies > Create Policy.
    2. Require: Windows 10+, BitLocker enabled.
    3. Link to CA: Require compliant devices.
    • PowerShell Example:
      # Requires Intune Graph access
      $complianceParams = @{ /* JSON for policy */ }
      New-IntuneDeviceCompliancePolicy -BodyParameter $complianceParams
    • Impact: Shortens offline validity by enforcing checks on reconnect.

    5. Administrative Revocation

    Admins revoke PRTs via Graph, invalidating on reconnect.

    • Additional Details: Affects refresh tokens; access tokens expire in ~1 hour. Use with CAE for near-real-time.
    • Working PowerShell Example:
      Connect-MgGraph -Scopes "User.ReadWrite.All"
      $user = Get-MgUser -UserId "[email protected]"
      Revoke-MgUserSignInSession -UserId $user.Id
      Update-MgUser -UserId $user.Id -AccountEnabled $false
    • Impact: Flags PRTs for invalidation; delayed until reconnect.

    6. Password Reset or Account Changes

    Invalidates password-based PRTs; requires re-auth for new issuance.

    • Additional Details: SSPR or admin reset triggers; non-password PRTs (e.g., FIDO2) may persist.
    • Configuration Example: Enable SSPR in Entra; users reset via myaccount.microsoft.com.
    • Impact: Forces renewal failure on reconnect post-change.

    Table 2: Control Mechanisms Comparison

    MechanismConfigurability LevelOffline Renewal ImpactReconnect EnforcementExample Use Case
    SIFHigh (intervals in hours/days)Delays renewal promptRe-auth requiredRisky users needing frequent MFA
    Token ProtectionMedium (enable per app)Binding validationBlocks unboundPreventing token theft
    CAEHigh (events/policies)Real-time revocationClaim challengeLocation-based access control
    Device ComplianceHigh (Intune rules)Compliance checkBlocks non-compliantEnforcing patches post-hibernation
    Admin RevocationManual (per user)Invalidation flagImmediate blockCompromised account response
    Password ResetUser/Admin-initiatedInvalidationRe-auth with new credsPost-breach remediation

    Limitations on Direct Control

    The 4-hour renewal and 90-day inactivity are hardcoded for reliability—no API or policy alters them. Controls are reactive (on reconnect), not proactive offline. TPM failures add uncontrolled invalidation.

    Sample Scenarios with Working Details

    1. High-Security Environment with SIF and Token Protection:
    • Setup: 1-hour SIF + Token Protection for Teams.
    • Scenario: Laptop hibernates for 48 hours. On wake/reconnect, SIF triggers MFA; Token Protection checks binding. If TPM intact, renewal succeeds; else, error 1002 blocks.
    • Outcome: Effective offline limit reduced to ~1 hour post-reconnect.
    1. CAE in Risky Offline Reconnect:
    • Setup: CAE enabled with IP policy (trusted: 192.168.1.0/24).
    • Scenario: User offline in trusted location, then reconnects from untrusted IP. CAE issues 401 challenge; client re-auths, denying if policy violated.
    • Outcome: PRT revoked mid-renewal attempt.
    1. Compliance Failure Post-Hibernation:
    • Setup: Intune policy requires OS build >22621.
    • Scenario: Device hibernates, misses update. On reconnect, compliance check fails; PRT renewal blocked until remediation.
    • Outcome: Forces update, invalidating stale PRT.
    1. Admin Revocation for Terminated Employee:
    • Setup: Run Revoke-MgUserSignInSession.
    • Scenario: Offline device uses cached PRT. On reconnect, invalidation applies; access denied.
    • Outcome: Near-instant post-reconnect block with CAE.

    Practical Considerations

    • Testing: Use report-only mode and sign-in logs (filter for PRT events). Simulate hibernation with powercfg /hibernate on and disconnect.
    • Usability vs. Security: Frequent SIF (e.g., every time) boosts security but may cause 30-second delays on mobile.
    • Monitoring: Query logs for errors like 1003 (unsupported device).
    • Best Practices: Combine mechanisms (e.g., SIF + CAE) for layered defense; migrate to MgGraph PowerShell.

    By mastering these controls, you can transform PRT delayed renewal from a potential vulnerability into a managed asset. Experiment in a lab environment to see the interplay.

    References

  • Understanding Tokens in Microsoft Entra ID: Types, Lifetimes, and Beyond

    Understanding Tokens in Microsoft Entra ID: Types, Lifetimes, and Beyond

    In the world of modern identity and access management, tokens are the digital keys that unlock secure access to resources. Microsoft Entra ID (formerly Azure Active Directory) relies on these tokens to authenticate users, authorize applications, and enforce security policies. Whether you’re a developer building apps, an admin managing access, or a security pro auditing sessions, grasping the nuances of token types, their lifespans, and how they interplay with features like Conditional Access, MFA, and authentication strengths is crucial. This post dives deep into these elements, complete with tables, scenarios, and references to official Microsoft documentation.

    We’ll cover token types and lifetimes first, then explore how Conditional Access policies influence them, the ties to MFA and authentication strengths, resource and application access patterns, and finally, who (or what) can end a token’s life—think admin revocations or even a simple laptop hibernation.

    Token Types in Entra ID: The Building Blocks

    Entra ID issues several token varieties, each serving a distinct role in the authentication and authorization flow. They primarily follow OAuth 2.0 and OpenID Connect standards, with JSON Web Tokens (JWTs) as the common format for portability and verifiability.

    Here’s a quick comparison table of the core token types:

    Token TypePurposeFormatKey Claims/FeaturesTypical Use Case
    Access TokenAuthorizes access to protected resources (e.g., APIs) on behalf of a user. Not for proving identity.JWT (opaque to clients)aud (audience/resource), scp (scopes), exp (expiry), iss (issuer). Versions: v1.0 (Entra-only apps), v2.0 (consumer support).Calling Microsoft Graph API for email access in a mobile app.
    ID TokenProves successful authentication and provides user identity details for the client app.JWTsub (subject/user ID), email, name, iat/nbf/exp (timestamps), nonce (anti-replay).Signing into a web app and displaying user profile info.
    Refresh TokenRequests new access/ID tokens without re-authentication. Long-lived for seamless sessions.Opaque stringBound to user+client combo; self-renewing. Types: Confidential (secure apps), Public (e.g., SPAs).Background refresh of an expired access token in a desktop client.
    Primary Refresh Token (PRT)Device-bound token for SSO across apps on registered devices (Windows, iOS, etc.). Carries device claims for policy enforcement.Secure artifactTypes: Registered (Entra-joined devices), Unregistered (personal devices). Includes NGCPRT (Next Gen Crypto PRT) for enhanced security.SSO to Teams and Outlook on a compliant Windows laptop.

    Access tokens are the workhorses for resource calls—clients send them to APIs, which validate claims like audience (aud) and issuer (iss) against OpenID Connect metadata. ID tokens, meanwhile, are client-facing proofs of auth, packed with user claims but unsuitable for authorization. Refresh tokens keep sessions alive by trading themselves for fresh pairs, while PRTs supercharge device SSO, embedding compliance info for Conditional Access checks.

    Scenario: Building a Multi-Tenant App
    Imagine developing a SaaS tool that integrates with Microsoft 365. You request an authorization code flow, yielding an ID token for user login (verifying aud matches your app ID) and an access token scoped to Mail.Read. A refresh token handles token rotation every 90 days. For device users, a PRT enables silent SSO across tenants.

    Token Lifetimes: Defaults, Configurability, and Variability

    Token lifetimes balance security (short-lived = less exposure) with usability (no constant re-auth). Entra ID defaults are randomized for resilience, but you can tweak them via policies.

    • Access Tokens: 60-90 minutes (avg. 75 min), variable to avoid thundering herd issues. With Conditional Access Sign-in Frequency (SIF), add the interval (e.g., 1-hour SIF + 75-min token = up to 2.5-hour sessions). Configurable: 10 min to 1 day via Token Lifetime Policies (TLPs).
    • ID Tokens: Fixed 1 hour. Configurable: 10 min to 1 day, controlling app session expiry.
    • Refresh Tokens: 24 hours (SPAs, due to cookie restrictions) or 90 days (others). Self-renewing; max inactive period is 90 days. Not configurable—use SIF instead.
    • PRTs: 90 days, renewed every 4 hours on Windows (or on reconnect). Limited by SIF controls.

    Configurable Token Lifetimes (CTL): Apply organization-wide or per-app/service principal via Microsoft Graph (e.g., New-MgPolicyTokenLifetimePolicy). Requires Entra ID P1. Can’t override for refresh/PRT; SAML tokens get 1-hour default + 5-min skew.

    Table: Lifetime Impacts by Feature

    Feature/PolicyAccess Token EffectID Token EffectRefresh/PRT Effect
    Default60-90 min1 hour90 days / 90 days
    CTL Policy10 min-1 day10 min-1 dayN/A
    SIF (1 hour)+SIF interval (up to 2.5 hours)N/AControls max session
    CAE EnabledUp to 28 hours (long-lived)UnaffectedRevocation on events, not expiry

    Scenario: Enforcing Shorter Lifetimes for High-Risk Apps
    For a finance app, set a TLP to 15-min access tokens. Users re-auth every 15 min, but a 90-day refresh token minimizes prompts—until SIF kicks in for weekly interactive MFA.

    Conditional Access Policies: Shaping Token Behavior

    Conditional Access (CA) policies dynamically evaluate signals like user risk, location, and device compliance to grant/deny access, directly influencing tokens.

    • Session Lifetime Controls: Use “Sign-in frequency” to cap sessions (e.g., every 8 hours), overriding token expiry for re-eval. “Persistent browser session” extends via PRT for compliant devices.
    • Token Protection: A CA session control binding refresh tokens to devices (via PRT) to thwart replay attacks. Enforced for Exchange/Teams/SharePoint; blocks unbound tokens with errors like 1002 (no device state).
    • Continuous Access Evaluation (CAE): Extends access tokens to 28 hours while monitoring real-time events (e.g., account disable). Revokes via claim challenges on policy violations, integrated with CA for IP/location checks.

    Scenario: CA for Remote Workers
    Policy: Require compliant device + MFA for VPN access. On violation (e.g., risky IP), CAE revokes the 28-hour token instantly, forcing re-auth. Token Protection ensures only the bound device succeeds.

    MFA Correlation, Authentication Strengths, and Auth Types

    MFA ties deeply to tokens: Entra requires MFA satisfaction for tokens with MFA claims, embedding proofs in ID/access tokens. Authentication strengths refine this in CA, specifying method combos (e.g., password + Authenticator app).

    Built-in Strengths (non-editable):

    • MFA Strength: Password + any “something you have” (e.g., Authenticator push).
    • Passwordless MFA: FIDO2 key or Windows Hello (no password).
    • Phishing-Resistant MFA: FIDO2/CBA (multi-factor certs) for proof-of-possession.

    Custom strengths allow tailoring (e.g., FIDO2 + biometrics). Evaluated post-initial auth; unsatisfied prompts registration.

    Auth Types Covered:

    • OAuth 2.0: For access tokens (delegated/implicit flows).
    • OpenID Connect: Layers ID tokens on OAuth for auth.
    • SAML: Federated tokens (1-hour default).

    Scenario: Risk-Based MFA
    High-risk sign-in? CA policy requires Phishing-Resistant MFA strength. User taps FIDO2 key; token issues with claims proving resistance. Without it, access denied—correlating MFA directly to token validity.

    Table: MFA Methods by Strength

    MethodMFA StrengthPasswordlessPhishing-Resistant
    FIDO2 Security KeyYesYesYes
    Windows HelloYesYesYes
    Authenticator (Push)YesNoNo
    SMS/OTPYesNoNo

    Resource and Application Access: Tokens in Action

    Tokens drive access: Access tokens scope permissions (e.g., User.Read) for APIs; ID tokens bootstrap app sessions. Apps validate via metadata endpoints (e.g., /v2.0/.well-known/openid-configuration). For applications, PRTs enable SSO; refresh tokens support background access.

    Sample Flow (OAuth 2.0 + OIDC):

    1. User auths → ID token issued (1-hour life).
    2. App requests access token for Graph API → Scoped to resource.
    3. Expiry? Refresh token swaps for new pair.
      CA might interject: “Require MFA strength” → Token only if satisfied.

    Scenario: API Access in a Web App
    A React SPA uses MSAL.js: On login, gets ID token for UI, access token for backend proxy to Graph. CA policy blocks if from untrusted IP, revoking via CAE.

    Terminating Tokens: Revocation, Actions, and Scenarios

    Tokens don’t last forever—revocation ensures security. Who can terminate? Admins (via roles like Global Admin) revoke all refresh/PRTs per user (Revoke-MgUserSignInSession). Users self-revoke via portal. Apps enforce based on policies.

    Actions/Scenarios:

    • Admin Revoke: Instant for refresh/PRTs; access tokens expire naturally (1 hour). Impacts: New tokens blocked; sessions end on expiry.
    • Password Change/SSPR: Invalidates non-password-based tokens; PRTs require re-issue.
    • Account Disable/Delete: PRTs/tokens invalidated; cached sessions may linger until detection.
    • Network Disconnect: PRTs cached for offline SSO (up to 90 days); no termination, but renewal waits for reconnect (every 4 hours on Windows).
    • System Hibernation: No direct termination—PRT remains valid. Renewal delayed until wake + internet; if >90 days inactive, expires. TPM issues (e.g., post-hibernation failure) trigger recovery, invalidating PRT.
    • CAE Event: High risk? Policy revokes mid-session via claim challenge.

    Scenario: Emergency Revocation
    Suspected compromise: Admin disables account + revokes sessions. User on hibernated laptop wakes to expired PRT; network reconnect fails renewal due to disable—forced re-auth reveals block.

    Table: Termination Triggers

    TriggerAffected TokensTime to ImpactMitigation Example
    Admin RevokeRefresh/PRT/SessionImmediatePowerShell: Revoke-MgUserSignInSession
    Password ChangePRT/Non-password tokensOn next useRe-auth with new creds
    Network DisconnectNone (cached)NoneOffline SSO via PRT
    HibernationPRT (delayed renewal)Up to 90 daysWake + reconnect for renewal

    In summary, Entra ID tokens are a symphony of security and convenience—tune them wisely with CA and strengths. For hands-on, check the Graph API for TLPs or test CA policies in report-only mode.

    References

  • Adding an Application Registration\ Service Principal to another Application Registration\ Service Principal

    Adding an Application Registration\ Service Principal to another Application Registration\ Service Principal

    Typically when working with App Roles in Azure Active Directory for a single application registration or service principal and then self consuming that app role as an Application API Permission you would see in the Enterprise Application > Users and Groups blade that service principals are added.

    Every now and then a question comes up on assign service principals (application registrations) to other service principals (application registrations) without creating app roles. Is that possible?

    The answer is YES! It is possible.

    Here is how:

  • Get Primary, Secondary, Tertiary DNS values and more from Multiple Servers

    Get Primary, Secondary, Tertiary DNS values and more from Multiple Servers

    Came across a unique request to get primary, secondary, and tertiary DNS values for multiple computers/servers across the domain. I started writing the script and got what I wanted.

    Now this started off as just to query for DNS Server information, but then I thought to add other pieces to get myself a good Network Inventory of all the servers in the environment.

    I am utilizing the Win32_NetworkAdapterConfiguration WMI Class to get the required information.

    You can modify the script below to suit your needs. The complete list of settings that can be captured:

      string   Caption;
      string   Description;
      string   SettingID;
      boolean  ArpAlwaysSourceRoute;
      boolean  ArpUseEtherSNAP;
      string   DatabasePath;
      boolean  DeadGWDetectEnabled;
      string   DefaultIPGateway[];
      uint8    DefaultTOS;
      uint8    DefaultTTL;
      boolean  DHCPEnabled;
      datetime DHCPLeaseExpires;
      datetime DHCPLeaseObtained;
      string   DHCPServer;
      string   DNSDomain;
      string   DNSDomainSuffixSearchOrder[];
      boolean  DNSEnabledForWINSResolution;
      string   DNSHostName;
      string   DNSServerSearchOrder[];
      boolean  DomainDNSRegistrationEnabled;
      uint32   ForwardBufferMemory;
      boolean  FullDNSRegistrationEnabled;
      uint16   GatewayCostMetric[];
      uint8    IGMPLevel;
      uint32   Index;
      uint32   InterfaceIndex;
      string   IPAddress[];
      uint32   IPConnectionMetric;
      boolean  IPEnabled;
      boolean  IPFilterSecurityEnabled;
      boolean  IPPortSecurityEnabled;
      string   IPSecPermitIPProtocols[];
      string   IPSecPermitTCPPorts[];
      string   IPSecPermitUDPPorts[];
      string   IPSubnet[];
      boolean  IPUseZeroBroadcast;
      string   IPXAddress;
      boolean  IPXEnabled;
      uint32   IPXFrameType[];
      uint32   IPXMediaType;
      string   IPXNetworkNumber[];
      string   IPXVirtualNetNumber;
      uint32   KeepAliveInterval;
      uint32   KeepAliveTime;
      string   MACAddress;
      uint32   MTU;
      uint32   NumForwardPackets;
      boolean  PMTUBHDetectEnabled;
      boolean  PMTUDiscoveryEnabled;
      string   ServiceName;
      uint32   TcpipNetbiosOptions;
      uint32   TcpMaxConnectRetransmissions;
      uint32   TcpMaxDataRetransmissions;
      uint32   TcpNumConnections;
      boolean  TcpUseRFC1122UrgentPointer;
      uint16   TcpWindowSize;
      boolean  WINSEnableLMHostsLookup;
      string   WINSHostLookupFile;
      string   WINSPrimaryServer;
      string   WINSScopeID;
      string   WINSSecondaryServer;

    Since the scripts are querying for information it is best if it runs from a DC or a privileged server with an account that has privileged access.

    To get the results you need the following two scripts:

    I needed to get all the network information for all the domain controllers in the domain. So the following code retrieves it for me. This came really handy in viewing all the DNS settings setup on all the DCs and correcting them if needed.

    This will get the information and export to an excel file that you can have handy for reference or auditing. Hope this helps!

  • Active Directory Ports required between client and domain controllers

    Active Directory Ports required between client and domain controllers

    Active Directory uses several ports for communication between domain controllers and clients. These ports are required both by client computers and Domain Controllers. As an example, when a client computer tries to find a domain controller it always sends a DNS Query over Port 53 to find the name of the domain controller in the domain.

    • 53- DNS
    • 88- Kerberos
    • 123- Time Service
    • 135- for domain controllers-to-domain controller and client to domain controller operations.
    • 138- For File Replication Service between domain controllers.r
    • 139- For File Replication Service between domain controllers.
    • 389- For LDAP to handle normal queries from client computers to the domain controllers.
    • 445- File replication/SMB
    • 464- For change the password of user account
    • 636- secure LDAP
    • 3268- Global Catalog server
    • 3269 – Global Catalog server [Secure]
    • 5722-File replication, DFSR
    • 9389- ADDS web service
    • 53248- FRS RPC

    Above mentioned ports should be opened in Firewall between client computers and domain controllers, or between domain controllers, will enable Active Directory to function properly.

  • Cleaning up Office365 Groups Mess

    Cleaning up Office365 Groups Mess

    Office 365 Groups are a shared workspace for email, conversations, files, and events where group members can collectively get stuff done. It compliments the introduction of Microsoft Teams. The main thing to keep in mind is that this feature is still evolving.

    Why is it important to control Office 365 Group creation?

    This feature is enabled by default. So its better to put restrictions in place or later clean up sites, groups, permissions set by organization users.

    Which Group?

    SharePoint frequently reuses terms, which often makes conversations and forum posts a lot of fun. There’s at least three “Groups” in Office 365:

    • Active Directory Groups: Groups at the AD level. Outside of SharePoint. Useable across all site collections, and other applications. A “Sales Managers” AD group can be created once, updated in one place and used across all site collections in the tenant.
    • SharePoint Groups: Collections of users (people) and AD groups. Scoped to a single site collection. A “Sales Managers” SharePoint group would need to be created in each of the site collections and all updates repeated across all of the site collections.
    • Office 365 Groups: A new collaboration option! A combination of a mailbox and a site collection. Not a group useable for managing access to SharePoint sites.

    Office 365 Groups

    Office 365 Groups are a combination of an Exchange email account with the group’s name that is used to store conversations, and a “OneDrive – like” site collection to store files.

    A collection of Office 365 Groups facts:

    • Internally, to distinguish traditional groups from the new Office 365 Groups, Groups are called “Unified Groups”. Externally they should be called “Office 365 Groups”, not “SharePoint Groups”.
    • Creating a Group creates an AD Distribution group, an email address and a “hidden” SharePoint Site Collection. The site collection is not visible in the tenant admin pages. The AD group is not manageable from Azure AD, only from the tenant admin Groups pages. (You can see members in Azure AD, but cannot edit them.)
    • Groups can be created from:
      • Outlook (OWA).
      • A user’s OneDrive.
      • The “GROUPS” page in the tenant Admin site. Here you can create both “Office 365 Groups” and “security groups”.
    • Conversations are stored in Exchange inboxes and files are stored in SharePoint Site Collections.
    • Groups are defined and managed in Azure AD. (Which explains why the PowerShell cmdlets for Groups are not in the SharePoint Online cmdlet library.)
    • Each user may create up to 250 Groups and can be a member of up to 1,024 Groups. There’s no limit for number of Groups per tenant.
    • Emails can be sent in the name of the group by members. (Requires a PowerShell based change.)
    • Groups will not be deleted if the Group’s owner is deleted.
    • Groups use a OneDrive for Business site under the covers. (Template: GROUP#0)
    • URL for the files site collection looks like a normal team site instead of a OneDrive site:  https://yourdomain/sites/groupsitename
    • If there is a URL conflict, a number is appended to the name: https://yourdomain/sites/groupsitename51
    • URL for the mailbox is “guessable”: https://outlook.office365.com/owa/#path=/group/yourGroupName@yourDomain.onmicrosoft.com/people
    • Groups site collections are not (currently) displayed in the admin Site Collections page. You may discover their existence when you create a new site collection that has the same name as a group site. “The site collection already exists. Please enter a different address.”
    • PowerShell:
      • Get-SPOSite does not return Groups site collections, but you can access a Groups site by URL.
      • Get-SPOUser does not return users for Groups sites.
    • Groups file storage is counted against the tenant quota. It’s not considered to be a personal OneDrive. There is no “user” for the Group OneDrive. The mailbox can store up to 50GB of messages, posts and calendar entries. The SharePoint Site Collection has a max of 1TB.
    • Search: There is a search box, but it opens the Search Center in a new window/tab and searches all of SharePoint, not just the Groups file site.
    • The document library in the Group site is very much like a OneDrive for Business library. No ribbon, no custom columns, no metadata and no Content Types. The Groups library is very limited:
      • Only one library, and it’s not customizable.
      • Can’t check out/in. (I saw this listed as a feature, but it’s not in my tenants.)
      • Versioning is enabled (Major only)
      • Cannot add/delete columns (i.e. use any custom metadata that might be useful to search or eDiscovery.)
      • Cannot use workflows.
      • Cannot audit security from the browser.
      • No branding. Cannot be opened by SharePoint Designer.
    • The Site Collection is VERY limited.
      • Almost all of the links for site or list maintenance are redirected to the home page.
      • There is no Settings page.
      • There is no Site Permissions page, so there’s no Site Permissions page or 2nd tier recycle bin.
      • You cannot create new lists or libraries.
    • Library Sync: The Sync button works with the new OneDrive for Business sync client. So, keep in mind that group members of easily offline all of the content.
    • Recycle Bin:
      • There is a recycle bin, but you can only access the user level.
      • If you share a file with a non-member with “Edit”, they can delete the file, but get “Sorry, you don’t have access to this page” when they click the Recycle Bin link.
      • There is no Site Collection recycle bin page available. The Groups “owner” can’t recover files deleted by members.
    • Can be administered and reported on from PowerShell as part of the Exchange Online cmdlets.
      https://technet.microsoft.com/en-us/library/jj200780(v=exchg.160).aspx
      cmdlets: Get/Set/New/Remove-UnifedGroup and Get/Add/Remove-UnifiedGroupLinks
      https://support.office.com/en-us/article/Use-PowerShell-to-manage-Office-365-Groups-aeb669aa-1770-4537-9de2-a82ac11b0540
    • Groups can be disabled for all users. (PowerShell)
    • Groups can be disabled for a subset of users. (Requires PowerShell.)
    • Security:
      • New groups default to “Public”. Everyone has access. You must remember to choose Private when you create the group.
      • I can’t find a place to change Public/Private status after the group has been created.
      • The names of groups are not private. They will be seen in “Send to”, “Share” and other places where user names can be seen. All groups, public and private, are listed in the “Browse Groups” screens. (Train your users not to use group names that reveal confidential data. You know, names like “IT Layoff Planning Group”. 🙂 )
      • Files can be shared with the “group”. They will be listed in the “Shared with us” tab.
      • Files that are shared with the “group” will be visible to all users even for Private groups! (I think this is a bug!) (The user must know the URL to the Files site.)
      • Files can be “reshared”. Sam has a site named “My Private Group”, which is Private, He shares a file with Robert (with Edit or View). Robert can only see that one file in the group site. Robert shares with Susan. Susan can then share with………
      • Users who guess the URL to the file site can see the site, but no files, or only files shared with them. They can see the list of “members” and who the owner is.

    Groups vs. Team Sites

    Groups Team Sites
    Can add lists/libraries No Yes
    Can add pages No Yes
    Can add columns/metadata No Yes
    Can use Content Types No Yes
    Can hide membership No Yes
    Can brand No Yes
    Can be fully managed with PowerShell No Yes

    Cleaning up the mess

    So since this feature is enabled by default. Users in your organization may have already started creating groups and hidden SharePoint site.

    So first we need to disable this option right away.

    Prerequisites:

    Check your Company-level configuration settings

    Now need to check your company-wide configuration settings through the Get-MsolCompanyInfo Windows PowerShell cmdlet. This cmdlet will display your current company-wide configuration settings that affect all users. You specifically need to verify that the UserPermissionToCreateGroupsEnabled parameter is set to False.

    To check your Company-level configuration settings

    You will first need to connect to your Office 365 service. In the Windows Azure Active Directory Module for Windows PowerShell, type and enter the following:

    Connect-MsolService

    In the Sign in to your Account screen, enter your credentials to connect you to your service, and click Sign in.

    You will be returned to a prompt in the Windows Azure Active Directory Module.

    You will need to display your company-wide configuration settings. To do this, type and enter:

    Get-MsolCompanyInformation

    This will display a listing of the current configuration settings that apply to all users in your company.

    As you can see the value for the UsersPermissiontoCreateGroupsEnabled setting is True. We need to change this to False.

    To change the UsersPermissionToCreateGroupsEnabled setting value

    You will first need to use the Set-MsolCompanySettings cmdlet to change the UsersPermissionToCreateGroupsEnabled parameter to False. In the Windows Azure Active Directory Module for Windows PowerShell, type and enter the following:

    Set-MsolCompanySettings - UsersPermissionToCreateGroupsEnabled $False
    

    You will be returned to a prompt in the Windows Azure Active Directory Module.

    After changing the setting, you then need to run the Get-MsolCompanyInfo cmdlet to verify that the value has changed to True.

    Get-MsolCompanyInfo

    After running the cmdlet, check the displayed information to verify that the UsersPermissionToCreateGroupsEnabled setting value has changed to False.

    Identifying the site collections in PowerShell

    Connect to SharePoint

    #Connecting to SharePoint
    
    #User account with Global Admin Permissions
    $adminUPN="[email protected]"
    
    #Organization Name (myorganizationinc.onmicrosoft.com)
    $orgName="myorganizationinc"
    
    #Prompting and using the password
    $userCredential = Get-Credential -UserName $adminUPN -Message "Type the password."
    
    #Making the Connection
    Connect-SPOService -Url https://$orgName-admin.sharepoint.com -Credential $userCredential

    Get a list of Site Collections

    Get-SPOSite -Detailed | Format-Table -AutoSize

    More than likely the Group SharePoint Site is restricted to the user that may have created it. You may get this error when trying to remove it:

    To remove it you need to take ownership as the CollectionOwner

    Set-SPOUser -Site http://myorganizationinc.sharepoint.com/sites/<YourGroupsSite> -LoginName [email protected] -IsSiteCollectionOwner $true

    Now if you want to do this for all the site collections:

    $Sites = Get-SPOSite
    ForEach ($Site in $Sites)
    {
    Set-SPOUser -Site $site -LoginName [email protected] -IsSiteCollectionOwner $true
    }

    Once this is applied the admin will be able to remove the hidden Sharepoint collection. Remove the site collections that are no longer needed.

    Remove-SPOSite -Identity https://myorganizationinc.sharepoint.com/sites/<YourGroupsSite> -NoWait

    Deleting the Groups

    Now to delete the groups that the users created. Head over to the Office365 Admin Portal.

    Click the “Office 365 group” from the selection to show all groups (These should be all cloud based)

    Once the groups are displayed remove them as necessary.

    Groups are no longer in your environment.

    Planning for the future: Migration of Distribution Groups to Groups

    If you are in Hybrid mode you cannot user Groups in a clean fashion. It will get messy. Sooner or later you will need to plan for migration of your distribution groups to Groups. Know your current limitations and hold.

    Migrate distribution lists to Office 365 Groups – Admin help

    Distribution list eligibility for migration

    The following table lists which distribution lists are eligible or not eligible for migration

    Property Eligibility
    On-premise managed distribution list. Not eligible
    Nested distribution lists. Distribution list either has child groups or is a member of another group. Not eligible
    Moderated distribution list Not eligible
    Distribution lists with send on behalf settings Not eligible
    Distribution lists hidden from address lists Not eligible
    Distribution lists with member RecipientTypeDetails other than UserMailbox, SharedMailbox, TeamMailbox, MailUser Not eligible
    Distribution lists with member join or depart restriction as Closed Eligible. Converted to a private Office 365 Group.
    Distribution lists with custom delivery status notifications. ReportToManager = true, ReportToOriginator = false ReportToManager = false, ReportToOriginator = false Eligible. Office 365 groups don’t understand these properties, and delivery status notifications are always sent to the person that sent the email.
  • Create a Virtual Machine with 2 NICs in Azure Classic

    Create a Virtual Machine with 2 NICs in Azure Classic

    Unfortunately, in Azure you cannot create a Virtual Machine in the GUI with 2 Network Cards. You cannot even add a 2nd NIC to a VM once it has been created. The only way to create a VM with 2, is to specify the additional NIC’s at the time of creation and ONLY via powershell. I have compiled a Powershell script that will do this. I have also listed the commands next to each comment to get the value to put there. Copy the code below into a PS1 and launch it from a PowerShell window.

    ############## Change Values Below Here #############
    
    # Set Subscription that will be used. Get-AzureSubscription
    $subscr="Free Trial"
    
    # Cloud Service Name. Get-AzureService
    $svcname="Cloud Service"
    
    #Set Storage Account VM will be created in. Get-AzureStorageAccount
    $staccount="Storage01"
    
    # Name of the VM Provisioned
    $vmname="VM01"
    
    # Instance Size of the VM required
    $vmsize="Standard_DS2_v2"
    
    # Virtual Network Name. Get-AzureVNetConfig
    $vnetname="Virtual Network"
    
    # OS you want to Deploy
    # 2012 = "Windows Server 2012 R2 Datacenter"
    # 2008 = "Windows Server 2008 R2 SP1"
    
    $OSversion = "Windows Server 2008 R2 SP1"
    
    # vNic1 IP Address
    $vNic1IP = "10.0.2.11"
    $vNic1Subnet = "Live"
    
    # vNic2 IP Address
    $vNic2Name = "Replication"
    $vNic2IP = "10.0.1.11"
    $vNic2Subnet = "Replication"
    
    ############# DO NOT CHANGE VALUES BELOW HERE ############
    
    # Select Subscription and Storage
    Set-AzureSubscription -SubscriptionName $subscr -CurrentStorageAccountName $staccount
    
    # Get image for VM
    $image = Get-AzureVMImage `
    | where{$_.ImageFamily -eq $OSversion} `
    | sort PublishedDate -Descending `
    | select -ExpandProperty ImageName -First 1
    
    # Creates a new VM config with the VM name, its Size and the Image Used
    $vm1 = New-AzureVMConfig -Name $vmname -InstanceSize $vmsize `
    -Image $image
    
    # Asks you for the admin username and password for the machine
    
    $cred=Get-Credential -Message "Type the name and password of the local administrator account."
    $vm1 | Add-AzureProvisioningConfig -Windows -AdminUsername $cred.Username -Password $cred.GetNetworkCredential().Password
    
    ###### 2nd Network Card - Remove comments on next 2 lines if you need a 2nd NIC #
    
    #Add-AzureNetworkInterfaceConfig -Name $vNic2Name `
    # -SubnetName $vNic2Subnet -StaticVNetIPAddress $vNic2IP -VM $vm1
    
    # Create vNic1 - Will be the Default Gateway so assign to Correct Subnet
    Set-AzureSubnet -SubnetNames $vNic1Subnet -VM $vm1
    Set-AzureStaticVNetIP -IPAddress $vNic1IP -VM $vm1
    
    New-AzureVM -ServiceName $svcname –VNetName $vnetname –VMs $vm1