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.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. Steve
AD 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.)
Upgrade to MS Entra Connect Sync fail
I am trying to upgrade my Server 2022 to the latest verions of MS Entra Connect Sync and it fails. with error 14001. Researching it shows to Repair the Microsoft Visual C++ retistributables. I have done that without success. a KB said to uninstall all MS Entra Connect and it uninstalls the remaining components. However, the repair doesn't resolve the issue. I tried to uninstall the Microsoft viual C++ 2015-2019 as a note said MS Entra would install it again, but it does not. I try and install a fresh copy, however, I can't find the site to download. Where can I find this download version. Any other clues on fixing the error 14001. I do have full system backups to restore if needed microsoft visual C++ 2015-2019 Redistributable (x64) - 14.29.30036
Domain users not able to logon with their password event though it has not been changed....
Hi, we have this weird problem where some of the users suddenly can't login to their computer with the password they have used for almost 20 years (yes sorry, bad practise). When the user reports it I check that I can logon to the computer with my own account (not 20 year old password) which works fine. I check the event log for problems both on the client and the DC and all I see is see which I can relate to the problem is event id 4625 with an error code which means bad password. I check the AD account and see that pwdLastSet has a date in 2006 (not quite 20 years, but close) and I check that the account is not logged out or expired. Also make sure that the password never expires is enabled, so in my book these are all the checks needed and problem not solved. I then change the password to the same password that the user has had for almost 20 years and problem solved, but problem source not found. This has happend to 3-4 users within the last week or two, even a service user with domain admin permissions, only thing I pay note to that they have in common is the pwdLastSet in 2006, but I really can't seem to get my head around this being the issue. Also only other thing I can think of that has changed is that the old DC has been removed a few months ago, and a new 2025 DC has been introduced. promote/demote went without issues and this problem didn't surface before now several weeks after the DC change. So if anyone has experienced something similar or perhaps can point me in a direction for further troubleshooting please let me know. Thansk Thomas
