Active directory allowing old and new password after reset
We are using windows 2019 server and once password is reset (before expired), we see a behavior that old password is valid for 5mins after password reset. Our replication delay is 15 seconds and we haven't set registry key OldPasswordAllowedPeriod. By documentation https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/new-setting-modifies-ntlm-network-authentication it is mentioned that if OldPasswordAllowedPeriod is not set, default will be 60mins. So where is this 5 mins configured?
Registering user becomes local admin on Joined Devices
This setting works exactly as named, but the confusion is understandable because the privilege is invisible in the places people normally look. Per Microsoft's official docs (assign-local-admin): at the moment of Microsoft Entra join, two principals get added to the local administrators group — the Microsoft Entra Joined Device Local Administrator role and the user performing the join. This happens only during the join operation itself. It's not a directory role assignment, so it won't show up in role assignments, audit logs, or under "Device Administrators" — that's by design. Critically: users aren't directly listed in the local admin group; the privilege is delivered through the Primary Refresh Token (PRT) at sign-in. So: To validate on the device itself, sign in as the user and run whoami /groups — you should see the device-local Administrators SID. If you just changed the setting and want to force re-evaluation, run dsregcmd /refreshprt, then sign out and back in (lock/unlock won't trigger it — you need a fresh PRT, which can take up to ~4 hours to propagate otherwise). This setting only applies to joined devices, not registered (workplace-joined) ones — so your distinction there is correct. The "Manage Additional local administrators on all Microsoft Entra joined devices" link is a separate, tenant-wide mechanism (the same Device Administrator role) — it can't be scoped to specific devices, which is also worth knowing if you're trying to limit blast radius. If you want to stop this going forward for new joins without ripping out existing admins, set "Registering user is added as local administrator" to None, and consider a Windows Autopilot profile or Intune Local Users and Groups policy to manage membership going forward — existing devices won't be retroactively changed.
Hostname Character Limit
Still being limited to 15 characters for hostnames in 2019 is very upsetting. In an age where we are deploying servers in multiple data centres, whether that be on premise or in the cloud and having multiple environments as well means trying to come up with sensible hostnames in just 15 characters is basically impossible. I’m sure I am not the only person who is frustrated by this limit and would very much like it if Microsoft was to revisit this limit and increase it to bring it in line with the wonderful limit our Linux friends enjoy.Event 4768 for one user
Hi all, We have two domain controllers running server 2019 with Domain Functional Level 2016. We have one user who has been with us for almost a year, and they were suddenly getting a message in the last week that username or password were incorrect even though we confimed they were not. They were able to initally switch to another user and re-enter their username and log in, but now it won't allow that. On the domain controller I see events for the user Audit Failure 4768 with Result Code 0x6. This result suggests the username doesn't exist which isn't true. The account isn't being locked. Has anyone seen this before and know what the issue might be? thanks jm
Creating parent reverse lookup zone when child zones already exist — what happens?
We have an AD-integrated DNS environment that has accumulated a large number of reverse lookup zones over time, created without any parent zone — essentially DNS sprawl from years of admins creating individual subnet zones rather than working from a parent. We currently have approximately 80+ reverse lookup zones including: Dozens of x.10.in-addr.arpa zones covering various 10.x.x.x subnets Multiple x.172.in-addr.arpa zones A handful of others including 100.192.10.in-addr.arpa, 168.192.in-addr.arpa, 204.167.in-addr.arpa, 215.204.167.in-addr.arpa, 135.7.in-addr.arpa None of these were ever delegated from a parent zone — they were just created independently. The 10.in-addr.arpa zone does not exist. Domain controllers are a mix of Windows Server 2019 Standard (majority) and Windows Server 2025 Standard. Our goal is to create 10.in-addr.arpa as the consolidation point going forward — new registrations go there, and we migrate existing child zones into it one at a time, deleting old ones as we go at a pace we're comfortable with. Before touching anything, we need to understand what creating 10.in-addr.arpa will actually do to the existing child zones. Specifically: Will existing records in the child zones be deleted? We've seen the TechNet article documenting records vanishing when creating a child zone under an existing parent — does the same destructive behaviour occur in the reverse direction? Will auto-delegations be created in the new parent zone pointing to the existing child zones, and if so how quickly? Will the child zones continue to function normally for queries while the parent exists alongside them? Will dynamic registration start hitting the parent zone for subnets not covered by an existing child zone, or will something unexpected happen? We can't test this in a lab as we don't have a replica environment available, and can't risk touching production without understanding the behaviour first. Pointers to any documentation covering this specific scenario would also be appreciated — we've been unable to find anything that addresses creating the parent after the children already exist independently.
Enforcing LDAP Signing breaks ADDS Replication (repadmin.exe)
Hi All, After months of auditing Event ID 2889 and remediating application simple binds (clear text usernames/passwords over the wire), I was left with only SASL binds (that do not use signing). I proceeded to set LDAP signing to 'negotiate' as per the GPOs below, and several dozen Microsoft KBs and from the community e.g.. https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server Default Domain Controllers Policy Domain controller: LDAP server signing requirements: None: Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it Default Domain Policy Network security: LDAP client signing requirements: Negotiate signing: If Transport Layer Security/Secure Sockets Layer (TLS\SSL) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the options specified by the caller. If TLS\SSL has been started, the LDAP BIND request is initiated with the options that are specified by the caller. I still noted 1,000s of Event ID 2889s (0 – SASL Bind that does not use signing), primarily from DCs, and ::1 addresses I proceeded with enforcing LDAP signing ("Require Signing" for both GPO settings above) and noted: LDAP authentication was occurring via Kerberos (SASL/SPNEGO) with simple binds blocked as per tracing (and ldp.exe) confirmations: Error <8>: ldap_simple_bind_s() failed: Strong Authentication Required Error 0x2028 A more secure authentication method is required for this server. However, I came to work the next day and performed a manual replication: Repadmin /Syncall /APeD LDAP error 8 (Strong Authentication Required) Win32 Err 5. So I had to revert back to Negotiate. How can customers enforce LDAP signing if common Microsoft ADDS executables like repadmin.exe still use Simple Binds? Any ideas appreciated, thank you in advance. SteveAD Recycle Bin – “The specified value already exists” but Recycle Bin is non‑functional
I am unable to enable the Active Directory Recycle Bin in an on‑premises Active Directory forest. Environment On‑prem AD DS Forest Functional Level: Windows2016Forest Mixed DC versions (2016 / 2022) When attempting to enable the Recycle Bin using the following command: Enable-ADOptionalFeature -Identity "Recycle Bin Feature" -Scope ForestOrConfigurationSet -Target "domain.local" the operation fails with the error: “The specified value already exists” However, the AD Recycle Bin is clearly not operational. Observed behaviour Deleted objects are hard‑deleted immediately Nothing ever appears under CN=Deleted Objects LDAP queries using (isDeleted=TRUE) return no results msDS-deletedObjectLifetime and tombstoneLifetime are unset (defaults) CN=Optional Features does not exist in the Configuration naming context Running: Get-ADOptionalFeature "Recycle Bin Feature" shows EnabledScopes referencing an NTDS Settings object, rather than the forest naming context (e.g. DC=domain,DC=local). This strongly suggests that the Recycle Bin optional feature has never been successfully enabled at forest scope, but the environment is now in a state where the enable command is blocked because AD believes it already exists. At present: Recycle Bin is non‑functional Deleted objects cannot be recovered Re‑enabling the feature is not possible via PowerShell or ADAC Has anyone seen this state before, or is aware of a supported method to: correct the optional feature metadata, or complete Recycle Bin enablement properly at forest scope? Any guidance would be appreciated, especially if this requires Microsoft AD DS intervention rather than a configuration change. (Microsoft support routing has been problematic, so I’m hoping someone here may have encountered this scenario before.)
