- Remove From My Forums
-
Question
-
I have just pulled a vanilla Windows Server 2008 into my Windows Server 2003 domain. The server is happy until I promote it to a Domain Controller. Then I get the following error message regarding Group Policy:
«The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.»
I can’t find much info on technet regarding this. The Event Id is 1006, however the listed bunch of Error Code’s doesn’t include the one I’m getting which is 82 / Local Error.
I tried to push on with DNS and DHCP and things just got worse. So I’ve started again and figured not to just proceed until I can iron out this one Error code. Could it be encryption, some form of authentication issue between 2008 and 2003?
I’m completely lost and there’s really not much info out there…
Answers
-
Hello,
From your description, the Event 1006 with error code 82 is logged on your newly promoted Windows Server 2008 DC.
Based on my research, ldap bind error <82> tranlates to LDAP_LOCAL_ERROR, a very generic error. It is returned from the server for a generic substitute of «unknown error» on the DC.
To narrow down the issue, please answer the following questions:
- How many DCs in the Windows Server 2003 domain? If there are more than 2 DCs in the original domain, is also Event 1006 is logged on them?
- How often the Event 1006 is logged? They are logged in separate little ones or repeated ones with a time interval (5min).
- Is there any Group Policy related error events logged?
This problem may occur when all the ephemeral ports 1025-5000 are in use on the DC. When the Event 1006 is newly logged in Windows Server 2008 DC, run ‘netstat -ano’ immediately on the Windows Server 2003 DC to check whether all ephemeral ports (TCP: 1025-5000) are occupied by other processes. If so, please perform the following steps to maximize the ephemeral ports and reduce the TcpTimedWaitDelay number:
a. MaxUserPort (set to 65000)
http://technet2.microsoft.com/WindowsServer/en/library/730fb465-d402-4853-bacc-16ba78e9fcc01033.mspx?mfr=true1. Start Registry Editor.
2. Locate the following subkey in the registry, and then click Parameters:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
3. On the Edit menu, click New, and then add the following registry entry:
Value Name: MaxUserPort
Value Type: DWORD
Value data: 65000 (decimal)
Description: This parameter controls the maximum port number that is used when a
program requests any available user port from the system. Typically, ephemeral
(short-lived) ports are allocated between the values of 1024 and 5000 inclusive.4. Quit Registry Editor.
b) TcpTimedWaitDelay (set to 30)
http://technet2.microsoft.com/WindowsServer/en/library/38b8bf76-b7d3-473c-84e8-e657c0c619d11033.mspx?pf=true
Reducing this value from its default setting of 240 seconds will make ports expire sooner. This parameter determines the length of time that a connection stays in the TIME_WAIT state when it is being closed. While a connection is in the TIME_WAIT state, the socket pair cannot be reused.1. Start Registry Editor
2. Locate the following subkey in the registry, and then click Parameters: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
3. On the Edit menu, click New, and then add the following registry entry:
Value Name: TcpTimedWaitDelay
Value Type: DWORD
Value data: 30 (decimal)
4. Quit Registry Editor.Hope this will helps.
-
hi,
We had the same issue but could solve the problem with help from MS-Support!
The problem appears if you once did an authoritative restore of your AD — so the msDS-KeyVersionNumber property from the userobject «KRBTGT» was increased.
KB939820 (http://support.microsoft.com//kb/939820) addresses the same authentication problem! (the kb article describes authentication problems with rdp…..)after installing the hotfix to all our windows 2003 dc´s the problem was fixed!
Wulf
-
Marked as answer by
Friday, June 27, 2008 11:37 AM
-
Marked as answer by
| title | description | services | ms.service | ms.subservice | ms.topic | ms.date | ms.author | author | manager | ms.reviewer | ms.collection | ms.custom |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Troubleshoot hybrid Azure Active Directory-joined devices |
This article helps you troubleshoot hybrid Azure Active Directory-joined Windows 10 and Windows Server 2016 devices. |
active-directory |
active-directory |
devices |
troubleshooting |
08/29/2022 |
joflore |
MicrosoftGuyJFlo |
amycolannino |
jairoc |
M365-identity-device-management |
has-adal-ref |
Troubleshoot hybrid Azure AD-joined devices
This article provides troubleshooting guidance to help you resolve potential issues with devices that are running Windows 10 or newer and Windows Server 2016 or newer.
Hybrid Azure Active Directory (Azure AD) join supports the Windows 10 November 2015 update and later.
To troubleshoot other Windows clients, see Troubleshoot hybrid Azure AD-joined down-level devices.
This article assumes that you have configured hybrid Azure AD-joined devices to support the following scenarios:
- Device-based Conditional Access
- Enterprise state roaming
- Windows Hello for Business
[!NOTE]
To troubleshoot the common device registration issues, use Device Registration Troubleshooter Tool.
Troubleshoot join failures
Step 1: Retrieve the join status
- Open a Command Prompt window as an administrator.
- Type
dsregcmd /status.
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined: YES
EnterpriseJoined: NO
DeviceId: 5820fbe9-60c8-43b0-bb11-44aee233e4e7
Thumbprint: B753A6679CE720451921302CA873794D94C6204A
KeyContainerId: bae6a60b-1d2f-4d2a-a298-33385f6d05e9
KeyProvider: Microsoft Platform Crypto Provider
TpmProtected: YES
KeySignTest: : MUST Run elevated to test.
Idp: login.windows.net
TenantId: 72b988bf-xxxx-xxxx-xxxx-2d7cd011xxxx
TenantName: Contoso
AuthCodeUrl: https://login.microsoftonline.com/msitsupp.microsoft.com/oauth2/authorize
AccessTokenUrl: https://login.microsoftonline.com/msitsupp.microsoft.com/oauth2/token
MdmUrl: https://enrollment.manage-beta.microsoft.com/EnrollmentServer/Discovery.svc
MdmTouUrl: https://portal.manage-beta.microsoft.com/TermsOfUse.aspx
dmComplianceUrl: https://portal.manage-beta.microsoft.com/?portalAction=Compliance
SettingsUrl: eyJVcmlzIjpbImh0dHBzOi8va2FpbGFuaS5vbmUubWljcm9zb2Z0LmNvbS8iLCJodHRwczovL2thaWxhbmkxLm9uZS5taWNyb3NvZnQuY29tLyJdfQ==
JoinSrvVersion: 1.0
JoinSrvUrl: https://enterpriseregistration.windows.net/EnrollmentServer/device/
JoinSrvId: urn:ms-drs:enterpriseregistration.windows.net
KeySrvVersion: 1.0
KeySrvUrl: https://enterpriseregistration.windows.net/EnrollmentServer/key/
KeySrvId: urn:ms-drs:enterpriseregistration.windows.net
DomainJoined: YES
DomainName: CONTOSO
+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+
NgcSet: YES
NgcKeyId: {C7A9AEDC-780E-4FDA-B200-1AE15561A46B}
WorkplaceJoined: NO
WamDefaultSet: YES
WamDefaultAuthority: organizations
WamDefaultId: https://login.microsoft.com
WamDefaultGUID: {B16898C6-A148-4967-9171-64D755DA8520} (AzureAd)
AzureAdPrt: YES
Step 2: Evaluate the join status
Review the fields in the following table, and make sure that they have the expected values:
| Field | Expected value | Description |
|---|---|---|
| DomainJoined | YES | This field indicates whether the device is joined to an on-premises Active Directory.
If the value is NO, the device can’t do hybrid Azure AD-join. |
| WorkplaceJoined | NO | This field indicates whether the device is registered with Azure AD as a personal device (marked as Workplace Joined). This value should be NO for a domain-joined computer that’s also hybrid Azure AD-joined.
If the value is YES, a work or school account was added before the completion of the hybrid Azure AD-join. In this case, the account is ignored when you’re using Windows 10 version 1607 or later. |
| AzureAdJoined | YES | This field indicates whether the device is joined. The value will be YES if the device is either an Azure AD-joined device or a hybrid Azure AD-joined device.
If the value is NO, the join to Azure AD hasn’t finished yet. |
Continue to the next steps for further troubleshooting.
Step 3: Find the phase in which the join failed, and the error code
For Windows 10 version 1803 or later
Look for the «Previous Registration» subsection in the «Diagnostic Data» section of the join status output. This section is displayed only if the device is domain-joined and unable to hybrid Azure AD-join.
The «Error Phase» field denotes the phase of the join failure, and «Client ErrorCode» denotes the error code of the join operation.
+----------------------------------------------------------------------+
Previous Registration : 2019-01-31 09:16:43.000 UTC
Registration Type : sync
Error Phase : join
Client ErrorCode : 0x801c03f2
Server ErrorCode : DirectoryError
Server Message : The device object by the given id (e92325d0-xxxx-xxxx-xxxx-94ae875d5245) isn't found.
Https Status : 400
Request Id : 6bff0bd9-820b-484b-ab20-2a4f7b76c58e
+----------------------------------------------------------------------+
For earlier Windows 10 versions
Use Event Viewer logs to locate the phase and error code for the join failures.
- In Event Viewer, open the User Device Registration event logs. They’re stored under Applications and Services Log > Microsoft > Windows > User Device Registration.
- Look for events with the following event IDs: 304, 305, and 307.
:::image type=»content» source=»./media/troubleshoot-hybrid-join-windows-current/1.png» alt-text=»Screenshot of Event Viewer, with event ID 304 selected, its information displayed, and its error code and phase highlighted.» border=»false»:::
:::image type=»content» source=»./media/troubleshoot-hybrid-join-windows-current/2.png» alt-text=»Screenshot of Event Viewer, with event ID 305 selected, its information displayed, and its error code highlighted.» border=»false»:::
Step 4: Check for possible causes and resolutions
Pre-check phase
Possible reasons for failure:
- The device has no line of sight to the domain controller.
- The device must be on the organization’s internal network or on a virtual private network with a network line of sight to an on-premises Active Directory domain controller.
Discover phase
Possible reasons for failure:
- The service connection point object is misconfigured or can’t be read from the domain controller.
- A valid service connection point object is required in the AD forest, to which the device belongs, that points to a verified domain name in Azure AD.
- For more information, see the «Configure a service connection point» section of Tutorial: Configure hybrid Azure Active Directory join for federated domains.
- Failure to connect to and fetch the discovery metadata from the discovery endpoint.
- The device should be able to access
https://enterpriseregistration.windows.net, in the system context, to discover the registration and authorization endpoints. - If the on-premises environment requires an outbound proxy, the IT admin must ensure that the computer account of the device can discover and silently authenticate to the outbound proxy.
- The device should be able to access
- Failure to connect to the user realm endpoint and do realm discovery (Windows 10 version 1809 and later only).
- The device should be able to access
https://login.microsoftonline.com, in the system context, to do realm discovery for the verified domain and determine the domain type (managed or federated). - If the on-premises environment requires an outbound proxy, the IT admin must ensure that the system context on the device can discover and silently authenticate to the outbound proxy.
- The device should be able to access
Common error codes:
| Error code | Reason | Resolution |
|---|---|---|
| DSREG_AUTOJOIN_ADCONFIG_READ_FAILED (0x801c001d/-2145648611) | Unable to read the service connection point (SCP) object and get the Azure AD tenant information. | Refer to the Configure a service connection point section. |
| DSREG_AUTOJOIN_DISC_FAILED (0x801c0021/-2145648607) | Generic discovery failure. Failed to get the discovery metadata from the data replication service (DRS). | To investigate further, find the sub-error in the next sections. |
| DSREG_AUTOJOIN_DISC_WAIT_TIMEOUT (0x801c001f/-2145648609) | Operation timed out while performing discovery. | Ensure that https://enterpriseregistration.windows.net is accessible in the system context. For more information, see the Network connectivity requirements section. |
| DSREG_AUTOJOIN_USERREALM_DISCOVERY_FAILED (0x801c003d/-2145648579) | Generic realm discovery failure. Failed to determine domain type (managed/federated) from STS. | To investigate further, find the sub-error in the next sections. |
Common sub-error codes:
To find the sub-error code for the discovery error code, use one of the following methods.
Windows 10 version 1803 or later
Look for «DRS Discovery Test» in the «Diagnostic Data» section of the join status output. This section is displayed only if the device is domain-joined and unable to hybrid Azure AD-join.
+----------------------------------------------------------------------+
| Diagnostic Data |
+----------------------------------------------------------------------+
Diagnostics Reference : www.microsoft.com/aadjerrors
User Context : UN-ELEVATED User
Client Time : 2019-06-05 08:25:29.000 UTC
AD Connectivity Test : PASS
AD Configuration Test : PASS
DRS Discovery Test : FAIL [0x801c0021/0x80072ee2]
DRS Connectivity Test : SKIPPED
Token acquisition Test : SKIPPED
Fallback to Sync-Join : ENABLED
+----------------------------------------------------------------------+
Earlier Windows 10 versions
Use Event Viewer logs to look for the phase and error code for the join failures.
- In Event Viewer, open the User Device Registration event logs. They’re stored under Applications and Services Log > Microsoft > Windows > User Device Registration.
- Look for event ID 201.
:::image type=»content» source=»./media/troubleshoot-hybrid-join-windows-current/5.png» alt-text=»Screenshot of Event Viewer, with event ID 201 selected, its information displayed, and its error code highlighted.» border=»false»:::
Network errors:
| Error code | Reason | Resolution |
|---|---|---|
| WININET_E_CANNOT_CONNECT (0x80072efd/-2147012867) | Connection with the server couldn’t be established. | Ensure network connectivity to the required Microsoft resources. For more information, see Network connectivity requirements. |
| WININET_E_TIMEOUT (0x80072ee2/-2147012894) | General network timeout. | Ensure network connectivity to the required Microsoft resources. For more information, see Network connectivity requirements. |
| WININET_E_DECODING_FAILED (0x80072f8f/-2147012721) | Network stack was unable to decode the response from the server. | Ensure that the network proxy isn’t interfering and modifying the server response. |
HTTP errors:
| Error code | Reason | Resolution |
|---|---|---|
| DSREG_DISCOVERY_TENANT_NOT_FOUND (0x801c003a/-2145648582) | The service connection point object is configured with the wrong tenant ID, or no active subscriptions were found in the tenant. | Ensure that the service connection point object is configured with the correct Azure AD tenant ID and active subscriptions or that the service is present in the tenant. |
| DSREG_SERVER_BUSY (0x801c0025/-2145648603) | HTTP 503 from DRS server. | The server is currently unavailable. Future join attempts will likely succeed after the server is back online. |
Other errors:
| Error code | Reason | Resolution |
|---|---|---|
| E_INVALIDDATA (0x8007000d/-2147024883) | The server response JSON couldn’t be parsed, likely because the proxy is returning an HTTP 200 with an HTML authorization page. | If the on-premises environment requires an outbound proxy, the IT admin must ensure that the system context on the device can discover and silently authenticate to the outbound proxy. |
Authentication phase
This content applies only to federated domain accounts.
Reasons for failure:
- Unable to get an access token silently for the DRS resource.
- Windows 10 and Windows 11 devices acquire the authentication token from the Federation Service by using integrated Windows authentication to an active WS-Trust endpoint. For more information, see Federation Service configuration.
Common error codes:
Use Event Viewer logs to locate the error code, sub-error code, server error code, and server error message.
- In Event Viewer, open the User Device Registration event logs. They’re stored under Applications and Services Log > Microsoft > Windows > User Device Registration.
- Look for event ID 305.
:::image type=»content» source=»./media/troubleshoot-hybrid-join-windows-current/3.png» alt-text=»Screenshot of Event Viewer, with event ID 305 selected, its information displayed, and the ADAL error codes and status highlighted.» border=»false»:::
Configuration errors:
| Error code | Reason | Resolution |
|---|---|---|
| ERROR_ADAL_PROTOCOL_NOT_SUPPORTED (0xcaa90017/-894894057) | The Azure AD Authentication Library (ADAL) authentication protocol isn’t WS-Trust. | The on-premises identity provider must support WS-Trust. |
| ERROR_ADAL_FAILED_TO_PARSE_XML (0xcaa9002c/-894894036) | The on-premises Federation Service didn’t return an XML response. | Ensure that the Metadata Exchange (MEX) endpoint is returning a valid XML. Ensure that the proxy isn’t interfering and returning non-xml responses. |
| ERROR_ADAL_COULDNOT_DISCOVER_USERNAME_PASSWORD_ENDPOINT (0xcaa90023/-894894045) | Couldn’t discover an endpoint for username/password authentication. | Check the on-premises identity provider settings. Ensure that the WS-Trust endpoints are enabled and that the MEX response contains these correct endpoints. |
Network errors:
| Error code | Reason | Resolution |
|---|---|---|
| ERROR_ADAL_INTERNET_TIMEOUT (0xcaa82ee2/-894947614) | General network timeout. | Ensure that https://login.microsoftonline.com is accessible in the system context. Ensure that the on-premises identity provider is accessible in the system context. For more information, see Network connectivity requirements. |
| ERROR_ADAL_INTERNET_CONNECTION_ABORTED (0xcaa82efe/-894947586) | Connection with the authorization endpoint was aborted. | Retry the join after a while, or try joining from another stable network location. |
| ERROR_ADAL_INTERNET_SECURE_FAILURE (0xcaa82f8f/-894947441) | The Transport Layer Security (TLS) certificate (previously known as the Secure Sockets Layer [SSL] certificate) sent by the server couldn’t be validated. | Check the client time skew. Retry the join after a while, or try joining from another stable network location. |
| ERROR_ADAL_INTERNET_CANNOT_CONNECT (0xcaa82efd/-894947587) | The attempt to connect to https://login.microsoftonline.com failed. |
Check the network connection to https://login.microsoftonline.com. |
Other errors:
| Error code | Reason | Resolution |
|---|---|---|
| ERROR_ADAL_SERVER_ERROR_INVALID_GRANT (0xcaa20003/-895352829) | The SAML token from the on-premises identity provider wasn’t accepted by Azure AD. | Check the Federation Server settings. Look for the server error code in the authentication logs. |
| ERROR_ADAL_WSTRUST_REQUEST_SECURITYTOKEN_FAILED (0xcaa90014/-894894060) | The Server WS-Trust response reported a fault exception, and it failed to get assertion. | Check the Federation Server settings. Look for the server error code in the authentication logs. |
| ERROR_ADAL_WSTRUST_TOKEN_REQUEST_FAIL (0xcaa90006/-894894074) | Received an error when trying to get access token from the token endpoint. | Look for the underlying error in the ADAL log. |
| ERROR_ADAL_OPERATION_PENDING (0xcaa1002d/-895418323) | General ADAL failure. | Look for the sub-error code or server error code from the authentication logs. |
Join phase
Reasons for failure:
Look for the registration type and error code from the following tables, depending on the Windows 10 version you’re using.
Windows 10 version 1803 or later
Look for the «Previous Registration» subsection in the «Diagnostic Data» section of the join status output. This section is displayed only if the device is domain-joined and is unable to hybrid Azure AD-join.
The «Registration Type» field denotes the type of join that’s done.
+----------------------------------------------------------------------+
Previous Registration : 2019-01-31 09:16:43.000 UTC
Registration Type : sync
Error Phase : join
Client ErrorCode : 0x801c03f2
Server ErrorCode : DirectoryError
Server Message : The device object by the given id (e92325d0-7ac4-4714-88a1-94ae875d5245) is not found.
Https Status : 400
Request Id : 6bff0bd9-820b-484b-ab20-2a4f7b76c58e
+----------------------------------------------------------------------+
Earlier Windows 10 versions
Use Event Viewer logs to locate the phase and error code for the join failures.
- In Event Viewer, open the User Device Registration event logs. They’re stored under Applications and Services Log > Microsoft > Windows > User Device Registration.
- Look for event ID 204.
:::image type=»content» source=»./media/troubleshoot-hybrid-join-windows-current/4.png» alt-text=»Screenshot of Event Viewer, with event ID 204 selected and its error code, H T T P status, and message highlighted.» border=»false»:::
HTTP errors returned from DRS server:
| Error code | Reason | Resolution |
|---|---|---|
| DSREG_E_DIRECTORY_FAILURE (0x801c03f2/-2145647630) | Received an error response from DRS with ErrorCode: «DirectoryError». | Refer to the server error code for possible reasons and resolutions. |
| DSREG_E_DEVICE_AUTHENTICATION_ERROR (0x801c0002/-2145648638) | Received an error response from DRS with ErrorCode: «AuthenticationError» and ErrorSubCode is not «DeviceNotFound». | Refer to the server error code for possible reasons and resolutions. |
| DSREG_E_DEVICE_INTERNALSERVICE_ERROR (0x801c0006/-2145648634) | Received an error response from DRS with ErrorCode: «DirectoryError». | Refer to the server error code for possible reasons and resolutions. |
TPM errors:
| Error code | Reason | Resolution |
|---|---|---|
| NTE_BAD_KEYSET (0x80090016/-2146893802) | The Trusted Platform Module (TPM) operation failed or was invalid. | The failure likely results from a bad sysprep image. Ensure that the machine from which the sysprep image was created isn’t Azure AD-joined, hybrid Azure AD-joined, or Azure AD-registered. |
| TPM_E_PCP_INTERNAL_ERROR (0x80290407/-2144795641) | Generic TPM error. | Disable TPM on devices with this error. Windows 10 versions 1809 and later automatically detect TPM failures and complete hybrid Azure AD-join without using the TPM. |
| TPM_E_NOTFIPS (0x80280036/-2144862154) | TPM in FIPS mode isn’t currently supported. | Disable TPM on devices with this error. Windows 10 version 1809 automatically detects TPM failures and completes the hybrid Azure AD join without using the TPM. |
| NTE_AUTHENTICATION_IGNORED (0x80090031/-2146893775) | TPM is locked out. | Transient error. Wait for the cool-down period. The join attempt should succeed after a while. For more information, see TPM fundamentals. |
Network errors:
| Error code | Reason | Resolution |
|---|---|---|
| WININET_E_TIMEOUT (0x80072ee2/-2147012894) | General network time-out trying to register the device at DRS. | Check network connectivity to https://enterpriseregistration.windows.net. |
| WININET_E_NAME_NOT_RESOLVED (0x80072ee7/-2147012889) | The server name or address couldn’t be resolved. | Check network connectivity to https://enterpriseregistration.windows.net. |
| WININET_E_CONNECTION_ABORTED (0x80072efe/-2147012866) | The connection with the server was terminated abnormally. | Retry the join after a while, or try joining from another stable network location. |
Other errors:
| Error code | Reason | Resolution |
|---|---|---|
| DSREG_AUTOJOIN_ADCONFIG_READ_FAILED (0x801c001d/-2145648611) | Event ID 220 is present in User Device Registration event logs. Windows can’t access the computer object in Active Directory. A Windows error code might be included in the event. Error codes ERROR_NO_SUCH_LOGON_SESSION (1312) and ERROR_NO_SUCH_USER (1317) are related to replication issues in on-premises Active Directory. | Troubleshoot replication issues in Active Directory. These replication issues might be transient, and they might go away after a while. |
Federated join server errors:
| Server error code | Server error message | Possible reasons | Resolution |
|---|---|---|---|
| DirectoryError | Your request is throttled temporarily. Please try after 300 seconds. | This error is expected, possibly because multiple registration requests were made in quick succession. | Retry the join after the cool-down period |
Sync-join server errors:
| Server error code | Server error message | Possible reasons | Resolution |
|---|---|---|---|
| DirectoryError | AADSTS90002: Tenant UUID not found. This error might happen if there are no active subscriptions for the tenant. Check with your subscription administrator. |
The tenant ID in the service connection point object is incorrect. | Ensure that the service connection point object is configured with the correct Azure AD tenant ID and active subscriptions or that the service is present in the tenant. |
| DirectoryError | The device object by the given ID isn’t found. | This error is expected for sync-join. The device object hasn’t synced from AD to Azure AD | Wait for the Azure AD Connect sync to finish, and the next join attempt after sync completion will resolve the issue. |
| AuthenticationError | The verification of the target computer’s SID | The certificate on the Azure AD device doesn’t match the certificate that’s used to sign in the blob during the sync-join. This error ordinarily means that sync hasn’t finished yet. | Wait for the Azure AD Connect sync to finish, and the next join attempt after the sync completion will resolve the issue. |
Step 5: Collect logs and contact Microsoft Support
-
Download the Auth.zip file.
-
Extract the files to a folder, such as c:temp, and then go to the folder.
-
From an elevated Azure PowerShell session, run
.start-auth.ps1 -v -accepteula. -
Select Switch Account to toggle to another session with the problem user.
-
Reproduce the issue.
-
Select Switch Account to toggle back to the admin session that’s running the tracing.
-
From the elevated PowerShell session, run
.stop-auth.ps1. -
Zip (compress) and send the folder Authlogs from the folder where the scripts were executed.
Troubleshoot post-join authentication issues
Step 1: Retrieve the PRT status by using dsregcmd /status
-
Open a Command Prompt window.
[!NOTE]
To get the Primary Refresh Token (PRT) status, open the Command Prompt window in the context of the logged-in user. -
Run
dsregcmd /status.The «SSO state» section provides the current PRT status.
If the AzureAdPrt field is set to NO, there was an error acquiring the PRT status from Azure AD.
-
If the AzureAdPrtUpdateTime is more than four hours, there’s likely an issue with refreshing the PRT. Lock and unlock the device to force the PRT refresh, and then check to see whether the time has been updated.
+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+
AzureAdPrt : YES
AzureAdPrtUpdateTime : 2020-07-12 22:57:53.000 UTC
AzureAdPrtExpiryTime : 2019-07-26 22:58:35.000 UTC
AzureAdPrtAuthority : https://login.microsoftonline.com/96fa76d0-xxxx-xxxx-xxxx-eb60cc22xxxx
EnterprisePrt : YES
EnterprisePrtUpdateTime : 2020-07-12 22:57:54.000 UTC
EnterprisePrtExpiryTime : 2020-07-26 22:57:54.000 UTC
EnterprisePrtAuthority : https://corp.hybridadfs.contoso.com:443/adfs
+----------------------------------------------------------------------+
Step 2: Find the error code
From the dsregcmd output
[!NOTE]
The output is available from the Windows 10 May 2021 update (version 21H1).
The «Attempt Status» field under the «AzureAdPrt» field will provide the status of the previous PRT attempt, along with other required debug information. For earlier Windows versions, extract the information from the Azure AD analytics and operational logs.
+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+
AzureAdPrt : NO
AzureAdPrtAuthority : https://login.microsoftonline.com/96fa76d0-xxxx-xxxx-xxxx-eb60cc22xxxx
AcquirePrtDiagnostics : PRESENT
Previous Prt Attempt : 2020-07-18 20:10:33.789 UTC
Attempt Status : 0xc000006d
User Identity : john@contoso.com
Credential Type : Password
Correlation ID : 63648321-fc5c-46eb-996e-ed1f3ba7740f
Endpoint URI : https://login.microsoftonline.com/96fa76d0-xxxx-xxxx-xxxx-eb60cc22xxxx/oauth2/token/
HTTP Method : POST
HTTP Error : 0x0
HTTP status : 400
Server Error Code : invalid_grant
Server Error Description : AADSTS50126: Error validating credentials due to invalid username or password.
From the Azure AD analytics and operational logs
Use Event Viewer to look for the log entries that are logged by the Azure AD CloudAP plug-in during PRT acquisition.
-
In Event Viewer, open the Azure AD Operational event logs. They’re stored under Applications and Services Log > Microsoft > Windows > AAD.
[!NOTE]
The CloudAP plug-in logs error events in the operational logs, and it logs the info events in the analytics logs. The analytics and operational log events are both required to troubleshoot issues. -
Event 1006 in the analytics logs denotes the start of the PRT acquisition flow, and event 1007 in the analytics logs denotes the end of the PRT acquisition flow. All events in the Azure AD logs (analytics and operational) that are logged between events 1006 and 1007 were logged as part of the PRT acquisition flow.
-
Event 1007 logs the final error code.
:::image type=»content» source=»./media/troubleshoot-hybrid-join-windows-current/event-viewer-prt-acquire.png» alt-text=»Screenshot of Event Viewer, with event IDs 1006 and 1007 selected and the final error code highlighted.» border=»false»:::
Step 3: Troubleshoot further, based on the found error code
| Error code | Reason | Resolution |
|---|---|---|
| STATUS_LOGON_FAILURE (-1073741715/ 0xc000006d) STATUS_WRONG_PASSWORD (-1073741718/ 0xc000006a) |
Note: WS-Trust is required for federated authentication. |
|
| STATUS_REQUEST_NOT_ACCEPTED (-1073741616/ 0xc00000d0) | Received an error response (HTTP 400) from the Azure AD authentication service or WS-Trust endpoint. Note: WS-Trust is required for federated authentication. |
Events 1081 and 1088 (Azure AD operational logs) would contain the server error code and error description for errors originating from Azure AD authentication service and WS-Trust endpoint, respectively. Common server error codes and their resolutions are listed in the next section. The first instance of event 1022 (Azure AD analytics logs), preceding events 1081 or 1088, will contain the URL that’s being accessed. |
| STATUS_NETWORK_UNREACHABLE (-1073741252/ 0xc000023c) STATUS_BAD_NETWORK_PATH (-1073741634/ 0xc00000be) STATUS_UNEXPECTED_NETWORK_ERROR (-1073741628/ 0xc00000c4) |
Note: WS-Trust is required for federated authentication. |
|
| STATUS_NO_SUCH_LOGON_SESSION (-1073741729/ 0xc000005f) | User realm discovery failed because the Azure AD authentication service was unable to find the user’s domain. |
|
| AAD_CLOUDAP_E_OAUTH_USERNAME_IS_MALFORMED (-1073445812/ 0xc004844c) | The user’s UPN isn’t in the expected format. Notes: |
whoami /upn should display the configured UPN. |
| AAD_CLOUDAP_E_OAUTH_USER_SID_IS_EMPTY (-1073445822/ 0xc0048442) | The user SID is missing in the ID token that’s returned by the Azure AD authentication service. | Ensure that the network proxy isn’t interfering with and modifying the server response. |
| AAD_CLOUDAP_E_WSTRUST_SAML_TOKENS_ARE_EMPTY (—1073445695/ 0xc00484c1) | Received an error from the WS-Trust endpoint. Note: WS-Trust is required for federated authentication. |
|
| AAD_CLOUDAP_E_HTTP_PASSWORD_URI_IS_EMPTY (-1073445749/ 0xc004848b) | The MEX endpoint is incorrectly configured. The MEX response doesn’t contain any password URLs. |
|
| AAD_CLOUDAP_E_HTTP_CERTIFICATE_URI_IS_EMPTY (-1073445748/ 0xc004848C) | The MEX endpoint is incorrectly configured. The MEX response doesn’t contain any certificate endpoint URLs. |
|
| WC_E_DTDPROHIBITED (-1072894385/ 0xc00cee4f) | The XML response, from the WS-Trust endpoint, included a Document Type Definition (DTD). A DTD isn’t expected in XML responses, and parsing the response will fail if a DTD is included. Note: WS-Trust is required for federated authentication. |
|
Common server error codes:
| Error code | Reason | Resolution |
|---|---|---|
| AADSTS50155: Device authentication failed |
|
Follow the instructions for this issue in Azure Active Directory device management FAQ to re-register the device based on the device join type. |
AADSTS50034: The user account Account does not exist in the tenant id directory |
Azure AD is unable to find the user account in the tenant. |
|
| AADSTS50126: Error validating credentials due to invalid username or password. |
|
To acquire a fresh PRT with the new credentials, wait for the Azure AD password sync to finish. |
Common network error codes:
| Error code | Reason | Resolution |
|---|---|---|
| ERROR_WINHTTP_TIMEOUT (12002) ERROR_WINHTTP_NAME_NOT_RESOLVED (12007) ERROR_WINHTTP_CANNOT_CONNECT (12029) ERROR_WINHTTP_CONNECTION_ERROR (12030) |
Common general network-related issues. |
Get more network error codes. |
Step 4: Collect logs
Regular logs
- Go to https://aka.ms/icesdptool to automatically download a .cab file containing the Diagnostic tool.
- Run the tool and repro your scenario.
- For Fiddler traces, accept the certificate requests that pop up.
- The wizard will prompt you for a password to safeguard your trace files. Provide a password.
- Finally, open the folder where all the collected logs are stored, such as %LOCALAPPDATA%ElevatedDiagnosticsnumbers.
- Contact Support with contents of the latest .cab file.
Network traces
[!NOTE]
When you’re collecting network traces, it’s important to not use Fiddler during repro.
- Run
netsh trace start scenario=internetClient_dbg capture=yes persistent=yes. - Lock and unlock the device. For hybrid-joined devices, wait a minute or more to allow the PRT acquisition task to finish.
- Run
netsh trace stop. - Share the nettrace.cab file with Support.
Known issues
- If you’re connected to a mobile hotspot or an external Wi-Fi network and you go to Settings > Accounts > Access Work or School, hybrid Azure AD-joined devices might show two different accounts, one for Azure AD and one for on-premises AD. This UI issue doesn’t affect functionality.
Next steps
- Troubleshoot devices by using the
dsregcmdcommand. - Go to the Microsoft Error Lookup Tool.
Group policy error (LDAP Bind fails)
Posted on 18/05/2012 Updated on 18/05/2012
On some systems (in my cases Remote Desktop Session Hosts (RDSHs)) the following error appears in the System event log:
Event ID: 1006
Description: The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.
Source: GroupPolicy
Level: Error
User: USER_ACCOUNT
Computer: YOUR_SYSTEM
Logged: DATE_AND_TIME
Task Category: None
Keywords:
OpCode: (1)
The event source is GroupPolicy, which means the group policy client. The description tells us the processing of group policies failed, because Windows couldn’t authenticate to the Active Directory (AD) service server side (so on a domain controller (DC)), a conclusion from the fact the LDAP Bind function call has failed. The Details tab shows us the exact error code (see the field ErrorCode) is 49.
Figure 1
Figure 2
Figure 3
Side note: the event source GroupPolicy is technically registered with the name “Microsoft-Windows-GroupPolicy” (HKEY_LOCAL_MACHINESYSTEMCurrentControlSetserviceseventlogSystemMicrosoft-Windows-GroupPolicy). The DLL (gpsvc.dll) is configured here, but there is also a referral to a GUID ({aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}) for more information through the REG_EXPAND_SZ named value providerGuid. A provider with this GUID is registered in the registry at the location HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWINEVTPublishers{ aea1b4fa-97d1-45f2-a64c-4d69fffd92c9} (HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWINEVTPublishers is the place where event providers are registered), which contains the provider’s name (Microsoft-Windows-GroupPolicy) and new referrals to the DLL that is used for the event logging (gpsvc.dll).
Side note: LDAP stands for Lightweight Directory Access Protocol and is a protocol used to communicate to directory servers (like Active Directory (AD) servers, called domain controllers). When setting up an LDAP connection there could be some initialization phase to set it up. This is called the Bind (hence LDAP Bind) and the action is called binding. This includes (but is not limited to) authentication.
What is error code 49? The error and its error codes are described on http://technet.microsoft.com/en-us/library/cc727283(v=ws.10).aspx, where we can read 49 means “Invalid credentials”. This means a logged on user has invalid credentials, so he/she can’t authenticate to AD to get his/her user group policies. It’s impossible to log on with invalid credentials, so this means the user had valid credentials at the time of logon, but the credentials became invalid while he/she was logged on (so during the session) in a way where the Kerberos tickets for that user are expired too (those tickets are used for authentication to Kerberos aware services (the story about Kerberos can be quite complex, so I’m making it simple here)). This is not always the case though. For example, somebody can be logged on and received Kerberos tickets and then an administrator changes your password. The tickets of the logged on user are still valid though (that is, for the rest of the ticket lifetime). Anyway, the thing is there could be another reason for this error… As I always say: don’t take those error messages too literally.
Another known cause for this error seems to be a name resolution problem. Check if your server has been registered correctly in DNS, doesn’t contain incorrect hosts file (in %windir%System32driversetc) entries, doesn’t contain incorrect lmhosts.sam file (also in %windir%System32driversetc) entries. Especially when your system has been built up based on a “specific” image (which is not sysprepped), these things should be checked for. By the way, it’s a best practice to use “generic” images (sysprepped) to deploy new systems. As a good IT administrator I have checked all those things, but no luck… Well, I mean everything was fine, so I hadn’t found the cause of the logged error yet :-s
I started to look and look and look at those errors… Over and over again… The weird thing is this error is logged for multiple users, but only for a few of them. And there is no DC being mentioned in the event (see figure 2: EventData – DCName)… Also, the error is always logged every night between 0 and 5 AM (local time). After that I see successful group policy events being logged, even for the same users! To be more precise I get the following successful System events (the time moments clearly differ from those from the previous screenshots, but that doesn’t really matter):
Event ID: 1503
Description: The Group Policy settings for the user were processed successfully. New settings from 10 Group Policy objects were detected and applied.
Source: GroupPolicy
Level: Information
User: USER_ACCOUNT
Computer: YOUR_SYSTEM
Logged: DATE_AND_TIME
Task Category: None
Keywords:
OpCode: (1)
Figure 4
Figure 5
Figure 6
Then a colleague of mine, Jo Jacobs, told me some users once had time restrictions to logon! Hey how! I checked the account settings in AD for the users having such a GP error being logged in the System event and oh yes, indeed, those users were time restricted between 0 and 5 AM every day! Users who don’t have this error being logged obviously had no time restriction at all. You can change those time restrictions in the AD management console (on WS03 that’s Active Directory Users and Computers (dsa.msc)): select the user object, right-click it, select Properties, go to the tab “Account” and click the button “Logon Hours…”. The dialog box “Logon Hours for USER” appears and you can clearly see the white pieces, representing the time frames where the user is denied to logon (the blue time frames show us when the user is allowed to logon).
Figure 7
The solution is simple: if you need those time restrictions, then ignore the error events. If you don’t need those time restrictions, remove them and the errors will disappear too. In our case time restrictions were once necessary for some users, but not anymore. So it seems some users still have old settings! We are planning to remove the time restrictions! You see, sometimes hunting error events can help you keep your environment clean and compliant! J
For those who want to automate all this you can execute the following PowerShell (PS) script. It looks for every user in your domain and checks for his/her Logon Hours. If there are time restrictions, those are removed. Note you should replace the first line with your own LDAP path.
$URL = “LDAP://DC=DOMAIN,DC=TLD”;
$root = New-Object DirectoryServices.DirectoryEntry $URL
$ds = New-Object DirectoryServices.DirectorySearcher
$ds.SearchRoot = $root
$ds.filter = “objectCategory=Person”
$src = $ds.FindAll()
Write-Host $src.Count ” user objects found.`n”
$src | %{
$de = $_.GetDirectoryEntry()
$LH = New-Object ‘Byte[]’ 21
For ($k = 0; $k -le 20; $k = $k + 1)
{
$LH[$k] = [byte]255
}
if (diff $de.logonHours.Value $LH)
{
$de.logonHours.Value = $LH
$de.SetInfo()
Write-Host -f yellow (“Changed:`t” + $de.properties[“sAMAccountName”])
Start-Sleep -m 200
}
else
{
Write-Host -f green (“Unchanged:`t” + $de.properties[“sAMAccountName”])
}
}
The number of user objects is calculated first. Then every user’s Logon Hours is compared to the variable LH, which is an byte array of 21 “full bytes” (1111 1111), representing allowed logon all the time (so no restrictions). If Logon Hours is the same (so there are no restrictions), nothing further happens. Otherwise Logon Hours is set to this variable, effectively meaning all restrictions are removed.
One last set of “last things” J
- In the case described here (and that I have experienced) there were no invalid credentials, so again, don’t take those errors and error code descriptions always too literally. Of course it has something to do with credentials the user cannot really use anymore (i.e. during the time restrictions), so it is close.
- My case explains why there is no DC mentioned in the error details: because of the time restrictions it has nothing to do with a specific DC.
- You can use the great tool ADModify.net to change user attributes in bulk, but Logon Hours isn’t available… L It’s not even possible through the Custom tab where you can specify “custom” attributes. That’s because ADModify.net doesn’t support byte arrays and that’s what Logon Hours actually is (or otherwise called: an octet string). So you should use the script instead.
Ciao!
Pedro
Links:
- http://technet.microsoft.com/en-us/library/cc727283(v=ws.10).aspx
I had a very frustrating issue today with group policy at a client on a few member servers running Windows Server 2008 R2.
A quick google showed DNS as a cause — I checked my DNS configuration and it was correct so I discarded this as the reason.
A few member servers were receiving the following error:
Log Name: System
Source: Microsoft-Windows-GroupPolicy
Date: 12/01/2011 11:51:40 AM
Event ID: 1006
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: torwmg832.domain.local
Description:
The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.
On the details tab I was getting ErrorCode 49.
The following TechNet article from Microsoft says Error Code 49 is the following:
Error code 49 (Invalid credentials)
This error code might indicate that the user’s password expired while the user is still logged on the computer.
To correct invalid credentials:
1. Change the user’s password.
2. Lock/unlock the workstation.
3. Check if there are any system services running as the user account.
4. Verify the password in service configuration is correct for the user account.
http://technet.microsoft.com/en-us/library/cc727283.aspx
This error code description from Microsoft completely threw me off track diagnosing the computer account passwords, rejoining PC’s to the domain and diagnosing the Kerberos Key Distribution Center (KDC) service.
All tests against the domain using nltest for the computer account were passing successfully!
/SC_QUERY: — Query secure channel for Domain on ServerName
I was confident it was nothing to do with authentication!
There were so many forum posts on the Internet leading to DNS as being the cause for this error. I decided to revisit my name resolution even though DNS was working correctly.
I checked the local host file. It was full of entries.
Removed these entries and the problem was resolved. A very simple fix for such a painful problem.
Hopefully this post will stop others from going through my pain!