Mohammed Wasay

Tag: windows

  • 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

  • Get all the domains controllers in the AD forest along with their current FSMO roles

    Get all the domains controllers in the AD forest along with their current FSMO roles

    In a large enterprise an admin would need to keep track of all the domains in a AD forest, the domain names, the domain controllers (DC) , their IPs, and what FSMO roles does a DC hold. Wrote a little script to just do that…

  • Fix Active Directory broken security inheritance problem

    Fix Active Directory broken security inheritance problem

    Ran into a situation at a client location where in Active Directory, the security permissions applied to an OU were not getting inherited permissions on to the objects. Basically, security inheritance was broken.This causes a problem when the administrative accounts or groups needing to modify an attribute on the AD object throw errors, or are unable to edit the AD object.

    To find out which objects were not getting the inherited permissions run the following :

    I ran it on the entire domain to identity potential problem accounts. 🙂

    To fix the issue:

    Reference:

    https://docs.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.objectsecurity.areaccessrulesprotected?view=netframework-4.8
    https://blogs.msdn.microsoft.com/adpowershell/2009/10/22/viewconfigure-protected-acl-and-fixing-broken-inheritance/

  • Force Replication of all Domain Controllers on all Sites

    Force Replication of all Domain Controllers on all Sites

    If you want to replicate all Domain Controllers, then you have to start replication on each of them separately. This may take a while. To save time there is an easier way to force replication on all Domain Controllers of all Active Directory Sites.

    Log on to one of your Domain Controllers. Start Windows PowerShell with administrative privileges. Using the Get-ADDomain cmdlet we can get the domain name and the domain partition.

    Now depending on the size of your environment the results may take some time to appear. The final output should be something like this:

  • All of Windows Cipher Suites

    All of Windows Cipher Suites

    Working on a security project and I needed a reference guide as to what cipher suites are supported on what OS.

    So I have documented a list of the default cipher suites and their preferred order for every Windows Server version. These were gathered from fully patched operating systems.

    [su_note note_color=”#efacad”]These are the server defaults for reference only. I do not recommend using the default cipher suites or the order listed.[/su_note]

    [su_accordion]

    [su_spoiler title=”Windows Server 2003″]TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC4_56_SHA TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA[/su_spoiler]

    [su_spoiler title=”Windows Server 2008″]TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_MD5 SSL_CK_RC4_128_WITH_MD5 SSL_CK_DES_192_EDE3_CBC_WITH_MD5 TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA[/su_spoiler]

    [su_spoiler title=”Windows Server 2008 R2″]TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA SSL_CK_RC4_128_WITH_MD5 SSL_CK_DES_192_EDE3_CBC_WITH_MD5[/su_spoiler]

    [su_spoiler title=”Windows Server 2012″]TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_MD5 SSL_CK_RC4_128_WITH_MD5 SSL_CK_DES_192_EDE3_CBC_WITH_MD5 TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA[/su_spoiler]

    [su_spoiler title=”Windows Server 2012 R2″]TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA SSL_CK_RC4_128_WITH_MD5 SSL_CK_DES_192_EDE3_CBC_WITH_MD5[/su_spoiler]

    [su_spoiler title=”Windows Server 2016″]TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA SSL_CK_DES_192_EDE3_CBC_WITH_MD5 SSL_CK_RC4_128_WITH_MD5[/su_spoiler]

    [/su_accordion]

     

  • NSLookup still showing IP of demoted Domain Controller

    NSLookup still showing IP of demoted Domain Controller

    So had an interesting issue today where a Domain Controller (DC) was demoted yet the IP of the demoted DC was still showing up when running nslookup internaldomain.local

    Demoted DC: MWDC04 / IP: 10.14.111.111

    I had done the metadata cleanup and tried many suggestions when googling the subject. To my surprise none of the solutions I found worked.

    I had removed the IP address from the Primary DNS Server and saw entries for:

    (same as parent folder) Host(A)  10.14.111.111
    (same as parent folder) NameServer (NS)  10.14.111.111

    I also looked under internaldomain.local > _msdcs and deleted entries from there.

    After clearing the cache and waiting for replication, did a nslookup again and the IP was still there.

    Well, there are some good and bad things about Microsoft DNS.

    The BAD:

    You cannot search DNS values in DNS Management. You are limited to searching just the names.

    THE GOOD:

    All DNS entries are stored in a flat file on the DNS Server “C:\WINDOWS\system32\dns\internaldomain.local.dns” (The default location). JACKPOT!

    I opened it up in Notepad++, did a search for IP and DNS name of the demoted server(MWDC04-10.14.111.111) and started deleting matched entries. I was so surprised to find entries that were deeply buried under “domaindnszones” & “forestdnszones” and a few other subzones.

    Cleared the cache again and waited for replication. Once replication completed I tried nslookup internaldomain.local and this time it didn’t list the demoted DC anymore.

    I hope this saves others time, because finding a record in DNS might be like searching for a needle in a haystack!

  • ConfigMgr 2012 R2 – WSUS sync fails with HTTP 503 errors

    ConfigMgr 2012 R2 – WSUS sync fails with HTTP 503 errors

    Ran into this issue with ConfigMgr 2012 R2 where it was unable to synchronize Software Update Point with the WSUS server. A review of the component status messages for the SMS_WSUS_SYNC_MANAGER component on the primary site server reveals errors related to WSUS synchronization which are similar to the following:
    [su_note note_color=”#efacad”]Message ID: 6703 WSUS Synchronization failed. Message: The request failed with HTTP status 503: Service Unavailable. Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer. [/su_note]
    Got the following error when trying to open Update Services on the WSUS server

    [su_note note_color=”#efacad”]Error: Connection Error An error occurred trying to connect to the WSUS server. This error can happen for a number of reasons. Please contact your network administrator if the problem persists. Click the Reset Server Node to connect to the server again. [/su_note]

    In addition to the above, attempts to access the URL for the WSUS Administration website (i.e., http://CMCASSERVER:8530) fails with the error:

    [su_note note_color=”#efacad”]HTTP Error 503. The service is unavailable[/su_note]

    In this situation, the most likely cause is that the WsusPool Application Pool in IIS is in a stopped state, as shown below.

    Also, the Private Memory Limit (KB) for the Application Pool is probably set to the default value of 1843200 KB.

    If you encounter this problem, increase the Private Memory Limit to 4GB (4000000 KB) and restart the Application Pool. To increase the Private Memory Limit, select the WsusPool Application Pool and click Advanced Settings under Edit Application Pool. Then set the Private Memory Limit to 4GB (4000000 KB).

    After the Application Pool has been restarted, monitor the SMS_WSUS_SYNC_MANAGER component status, wcm.log and wsyncmgr.log for failures. Please note that it may be necessary to increase the Private Memory Limit to 8GB (8000000 KB) or higher depending on the environment.

    Now WSUS is back online!

  • Going back to the basics….moving out of Amazon Drive!

    Going back to the basics….moving out of Amazon Drive!

    As of June 8, 2017, it was announced that when when users try to sign up for Amazon Drive they will not be able to select an unlimited cloud storage option. Instead they can choose either 100 GB for $11.99 per year, or 1 TB for $59.99, with up to 30 TB available for an additional $59.99 per TB. (The prior pricing was unlimited everything for $59.99.) My data came up to about 5TB, which according to their new pricing structure would cost me $300+ (Data is always growing!!).

    That is quite costly for just 5TB of storage when I can buy two 8TB drives and have it locally in a RAID configuration or a mirrored set. I shopped around with other popular cloud providers but each and every one of them have some sort of limitations. I decided to purchase two 8TB drives and maintain it locally. 

    I found very little help on Google when searching for ways to move out of Amazon Drive with ease. I found a lot of cool little utilities but none were able to do a clean and consistent sync copy/move. It most cases the application would either hang, or incomplete the job.

    I tried a lot of tools to get a synced local copy but the process seemed harder and harder. I tried a lot of freeware and shareware utilities as well as those offered by Amazon. I am just listing my personal experiences here so that I can save time for those whole have a similar situation.

    Tools I tried:

    Amazon Drive Desktop Sync

    •  Horrible transfer speeds +
    • Buggy Software
    • Startup & Resuming files would delay download significantly.

    SymLink (MacOS/ Linux)

    • Somewhat works but metadata is lost.

    NetDrive

    • Mounts the Amazon Cloud Drive and a Network Drive
    • Constant disconnects + too many app updates
    • Application hangs with large files
    • Service needed to be restarted multiple times to connect with Amazon

    Cloudberry Explorer

    • Quirks around Admin Mode.
    • Ghostfiles (0kb) leftover.
    • Acts like an FTP Client but missing a lot features

    rClone (Banned)

    AllwaySync

    • The Oneway transfer feature is nice but it was taking a long time between files
    • This might have worked if my filebase was a whole lot smaller but failed for larger jobs.

    Expandrive

    • Similar to NetDrive but a whole lot stable, but would fail on larger files.

    Odrive

    • Horrible interface. Didn’t work most of time.

    & a few more applications…. that didn’t work out!

    Syncovery

    Syncovery was the  winner in my case. This tools was the best in speed and got me an exact copy out from Amazon Cloud drive. It supports resuming! It is available on all platforms. It has a nice layout and can run as a scheduled job!

    It took Syncovery literally 2 days to get all of my data downloaded. I was simply amazed at how efficient this tool was working. It maintained a consistent speed. Didn’t lose any metadeta. I ran a file check and all of them checked out 100%.

    The trial version worked in my case and I am considering getting the Pro version. It excelled where all other failed. It wasn’t a resource hog and did the job in the first go! Thank you Syncovery!

     

    Couple of lessons learned in getting success with all my data downloaded.

    1. Metadata is important especially when dealing with older files. Try not of lose it, as once it is lost there is no going back.
    2. Don’t copy to the same path as the original. Use an external drive and copy it there.
    3. If dealing with a lot of smaller files break them into chunks or batches to avoid application hang
    4. Apart from Syncovery, there were some utilities that might delete the files from Amazon and put them in Trash. Make sure you look there if you notice files missing file. It is most certainly there. I personally didn’t have this issue but some people have reported this with other utilities.
    5. Share your experiences to help out others.

    Conclusion

    I am in no way promoting a product from Syncovery, but based on my personal experience I found it to be the easiest to move the amount of data I had from Amazon down to my local server.  I am going to sway away from the public cloud space for a while at-least for my personal stuff. Based on the pricing, limitation of file size and types, and amount of data I have, I am still searching for good cloud store. I am evaluating ownCloud for now. If I ever goto a public cloud storage solution again, I am going to try my exit exercise/ strategy prior to bulk upload.

    Another strategy people are recommending is hosting all the files in a VM on AWS/ Google/ Azure. My issue there is access cost. If my access is within the VM I am good, but any data I am pulling or accessing out of the VM – I am paying for it!

  • Map a network drive using PowerShell

    Map a network drive using PowerShell

    Make sure you are using the latest version of PowerShell. On Windows 8/10 run it as administrator and type the following:

    New-PSDrive –Name “Z” –PSProvider FileSystem –Root “\\fileserver01\share” –Persist

    Where:

    Z – is the Drive Letter

    Within ” ” is the path of the network share that will be presented as the root of the drive letter Z

    The -Persist parameter so that you can not only see the name of your new drive in Windows explorer, but also know it’s still there the next time you logon.

    -Name <String>
    Specifies a name for the new drive. For persistent mapped network drives, type a drive letter. For temporary drives type you are not limited to drive letters.
    Required? true
    Position 1

    -PSProvider <String>
    Specifies the Windows PowerShell provider, for example, FileType or Registry.
    Required? true
    Position? 2

    -Root <String>
    Specifies the data store location, for example, \\Server\Drivers, or a registry key such as HKLM:\Software\Microsoft\Windows NT\CurrentVersion.
    Required? true
    Position? 3