Login Timestamp Error or Bad Timestamp Error (40105) on a Company Laptop 

One of our users reported that their company laptop displayed a Login Timestamp Error (also known as Bad Timestamp Error 40105) while attempting to sign in.

In most enterprise environments, this error occurs because the laptop's date and time are not synchronized with the organization's authentication server.


This commonly happens when:

• The laptop has been disconnected from the company network for several days.
• The device has not connected to the corporate VPN.
• The BIOS date and time are incorrect.
• Windows Time service is not running.

Fortunately, this issue can usually be resolved within a few minutes.

Table of Contents

1. What is Login Timestamp Error (40105)?
2. Why Does This Error Occur?
3. Solution 1: Restart Windows Time Service
4. Solution 2: Correct Date & Time from BIOS
5. How Windows Time Synchronization Works
6. Additional Troubleshooting
7. Frequently Asked Questions
8. Conclusion

What is Login Timestamp Error (40105)?

The Login Timestamp Error (40105) is an authentication error that occurs when the system time on your laptop differs significantly from the company's authentication server. Error 40105

Most organizations use technologies such as Active Directory, Kerberos Authentication, or Single Sign-On (SSO), which rely on accurate timestamps to validate login requests.

If the time difference exceeds the allowed limit, authentication fails.

Why Does This Error Occur?

The company's authentication server verifies your computer's system time before allowing access.

If your laptop clock is incorrect, Windows sends an invalid timestamp during authentication, causing the login request to fail. Windows Time Service


Common causes include:

• Incorrect BIOS date and time
• Windows Time service stopped
• Laptop disconnected from VPN for a long period
• CMOS battery issue
• Failed time synchronization with the domain controller

Quick Fix 1: Restart Windows Time Service

If you're able to sign in to Windows, restart the Windows Time service.

Steps

• Press Win + R
• Type services.msc
• Press Enter
• Locate Windows Time
• Right-click it
• Select Restart

If the service is stopped, click Start.
This forces Windows to begin time synchronization again.
Tip: You can also restart the service from Command Prompt (Run as Administrator):

• net stop w32time
• net start w32time

Quick Fix 2: Correct the Date and Time from BIOS (UEFI)

If Windows displays an incorrect time before connecting to the network, verify the BIOS clock. Login Timestamp Error 40105

Steps

Restart the laptop.
Enter BIOS/UEFI (usually F2, F10, F12, Delete, or Esc).
Navigate to Date & Time.
Update the correct date and time.
Press F10 to save.
Restart Windows.

Note: BIOS only stores the hardware clock. It does not synchronize with internet time servers.

How Windows Time Synchronization Works

After Windows starts and the device has network connectivity, it synchronizes the system clock using Network Time Protocol (NTP). Bad Timestamp Error

Key Information:

If the device cannot communicate with the domain controller or NTP server, the system time may become inaccurate.Login Timestamp Error Domain Login Error

Additional Troubleshooting

If the issue still exists, try the following:

• ✅ Connect the laptop to the company VPN.
• ✅ Restart the computer.
• ✅ Ensure Windows Time service is running.
• ✅ Verify the correct Time Zone.
• ✅ Check if the CMOS battery is weak (time resets after every shutdown).
• ✅ Run Windows Update.
• ✅ Contact your IT administrator if the device belongs to a corporate domain.

Frequently Asked Questions (FAQ)

What causes Login Timestamp Error (40105)?
The most common cause is an incorrect system date and time.

Can a VPN connection fix this issue?
Yes. Once connected to the corporate VPN, Windows may synchronize the system time with the company's domain controller.

Does changing BIOS time permanently fix the issue?
It fixes the hardware clock, but Windows still synchronizes time using the Windows Time service after startup.

Which protocol is used for Windows time synchronization?
Windows uses Network Time Protocol (NTP) over UDP Port 123.

Can a dead CMOS battery cause this error?
Yes. If the CMOS battery is weak, the BIOS clock may reset after every shutdown, causing repeated timestamp errors.

Conclusion

The Login Timestamp Error (40105) is usually caused by an incorrect system clock rather than a problem with your user account.

In most cases, restarting the Windows Time service or correcting the BIOS date and time resolves the issue. Once the laptop synchronizes with the company's authentication server, users should be able to sign in successfully.

If the problem continues, connect the laptop to the corporate VPN or contact your organization's IT support team for further assistance.

Related Articles

• How to Fix "A Trust Relationship Between This Workstation and the Primary Domain Failed"
• Common RDP Connection Issues and Their Solutions
• Windows Time Service Not Running – Complete Fix Guide
• Active Directory Authentication Troubleshooting
• How to Join a Windows Computer to a Domain
• How to Fix Windows Time Synchronization Failed

How to identify my wbs chargecode in powershell

A WBS (Work Breakdown Structure) / Charge code is usually not something Powershell can 'discover' automatically from your system because it's company-specific financial/project data (Stored in tools like SAP, ServiceNow, internal portals, or time-tracking systems).

1. Check Environment Variables (if your organization uses them)

Some companies push project/charge codes as environment variables.

Get-ChildItem Env:

Look for anything like:

• WBS
• CHARGECODE
• PROJECT
• COSTCENTER

2. Check Active Directory (if stored in AD)

Sometimes WBS/cost center is stored as a user attribute.

Get-ADUser -Identity $env:USERNAME -Properties *

Look for fields like:

• department
• extensionAttributeX
• employeeID
• costCenter

Filter only relevant fields:

Get-ADUser -Identity $env:USERNAME -Properties  department,extensionAttribute1,extensionAttribute2

If you got error like as you can see the image below so in screenshot, the error is very clear:

Get-ADUser : The term 'Get-ADUser' is not recognized

✅ What this means

Your PowerShell does not have the Active Directory module installed or loaded.

Get-ADUser comes from the ActiveDirectory module, which is:

• ✅ Available on domain-joined machines with RSAT installed
• ❌ Not available by default on normal Windows installs

✅ Fix it (step-by-step)

🔹 Option 1: Check if module exists but not loaded

Get-Module -ListAvailable ActiveDirectory

👉 If you see output well and good but if you are not seeing then leave it as of now.

Then just import it:

Import-Module ActiveDirectory

Option 2: Install RSAT (Most likely needed)

Since you’re a IT Support Engineer, this is probably your case.

Run:

Get-WindowsCapability -Name RSAT.ActiveDirectory* -Online

Install it:

Add-WindowsCapability -Online -Name RSAT.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

Option 3: If installation is blocked

In many corporate environments:

❌ You may NOT have permission to install RSAT

👉 Then:

Ask IT:

"Please enable RSAT Active Directory PowerShell module on my machine"

✅ After fixing

Use this correct command 

👉 Environment variables cannot start with numbers

✅ Correct version:

If your username is your ID:

Get-ADUser -Identity $env:USERNAME -Properties *

Or explicitly:

Get-ADUser -Identity 221843 -Properties *

Filter WBS / Charge info (after it works)

Get-ADUser -Identity $env:USERNAME -Properties * |
Select-Object Name, Department, Title, extensionAttribute1, extensionAttribute2

Disclaimer

Microsoft-365-L1-Desktop-Support-guide

This article is designed as a practical,User account disablement is a common L1-level ticket in enterprise environments. It may occur due to HR actions, security policy enforcement, inactivity, or administrative changes. L1 engineers must verify the reason carefully before enabling the account to avoid policy violations. This guide explains the standard enterprise workflow for handling disabled user accounts using Active Directory.

I will write article on each topic for single single blog -

I’ll break into real helpdesk categories:

1. Unlock user
2. Reset password
3. Enable / Disable account
4. Create new user
5. Add user to group
6. Remove user from group
7. Check login issues
8. Move user to correct OU
9. Basic permission via groups

Today we will see step by step Account & License Management  

👤 SCENARIO 1 — Enable / Disable account

 
🚫 SCENARIO — User Account Disabled


User account disablement is a common L1-level ticket in enterprise environments. It may occur due to HR actions, security policy enforcement, inactivity, or administrative changes. L1 engineers must verify the reason carefully before enabling the account to avoid policy violations.

This guide explains the standard enterprise workflow for handling disabled user accounts using Active Directory.


🔎 Symptoms Observed

• Users typically report:
• Cannot login to system
• Error message: “Your account has been disabled. Please contact your system administrator.”
• Outlook not connecting
• VPN authentication failing
• Teams login failure

1️⃣ Step 1 — Verify the Scenario (Important)

Before enabling the account, confirm:

Is this a rejoining employee?

Has HR approved account activation?

Is there an open service request ticket?

Was the account disabled due to security reasons?

Is this part of offboarding process?

⚠ Never enable an account without proper authorization.

2️⃣ Step 2 — L1 Action (Enable / Disable Account Procedure)

🖥 Using Active Directory Users and Computers (ADUC)

Method 1 — Via Properties

• Open ADUC
• Search for the user
• Right-click → Properties
• Go to Account tab
• Uncheck: Account is disabled
• Click Apply → OK

Method 2 — Quick Right-Click Option

• Open ADUC
• Locate the user
• Right-click on user

Select:

• ✔ Enable Account (if disabled)
• ✔ Disable Account (if requested by HR/Security)
• This is the fastest method used in L1 operations.

3️⃣ After Enabling — Inform the User

• Advise the user to:
• Lock PC (Windows + L)
• Log in again
• Connect VPN if working remotely
• Restart system if required
• If password expired, perform password reset as per policy.

4️⃣ When L1 Should Disable an Account

• L1 may disable accounts in cases such as:
• HR termination ticket
• Long leave request
• Security instruction
• Contract completion
• Lost device security precaution
• Always document ticket number and approval source.

🚨 Escalate If

• Immediately escalate to L2 / Security / HR if:
• Account disabled due to HR termination
• Security suspension case
• Insider threat investigation
• Legal hold case
• Unknown disablement with no ticket reference
• Account automatically re-disables (possible GPO or sync issue)

🧠 Real Helpdesk Insight

• In hybrid environments (On-Prem AD + Azure AD sync):
• If account is enabled in AD but still blocked in Microsoft 365
• Check Azure AD sync status
• Confirm sign-in status in Microsoft 365 Admin Center
• Sometimes cloud sign-in may be blocked separately.

✅ L1 Checklist (SOP Format)

• ✔ Identity verified
• ✔ Ticket approved
• ✔ Checked reason for disablement
• ✔ Account enabled via ADUC
• ✔ User informed
• ✔ Login tested
• ✔ Escalated if policy-related

🎯 Interview-Ready Statement

If interviewer asks how you handle disabled account cases:


“First, I verify the reason for disablement through ticket and HR approval. I never enable accounts without authorization. After validation, I enable the account via ADUC either through Properties → Account tab or right-click enable option. Then I guide the user to log in and monitor for replication issues. If the disablement is related to HR or security, I escalate immediately.”

Disclaimer

Microsoft-365-L1-Desktop-Support-guide

This article is designed as a practical, User onboarding is a critical responsibility for L1 Desktop Support teams in enterprise environments. When a new employee joins, IT must ensure proper account creation, access provisioning, and mailbox setup without security gaps or permission errors. In hybrid environments (On-Prem AD + Microsoft 365), the process involves Active Directory configuration followed by synchronization to Azure AD. This guide explains the standard real-world workflow followed by service desk engineers during new user creation.

I will write article on each topic for single single blog -

I’ll break into real helpdesk categories:

1. Unlock user
2. Reset password
3. Enable / Disable account
4. Create new user
5. Add user to group
6. Remove user from group
7. Check login issues
8. Move user to correct OU
9. Basic permission via groups

Today we will see step by step Account & License Management  

👤 SCENARIO 1 — Create new user (new user join)

✅ Step 1 — Create User in Active Directory


User accounts are created in:

Active Directory Users and Computers (ADUC)

You can open it via:

• dsa.msc

📍 Navigate to Proper OU


Inside ADUC:

 

• Expand Domain Name (Example: company.local)
• Navigate to correct OU (Organizational Unit) – e.g., Accounts / Users
• Right-click the OU
• Select New → User
• Fill Required Details:
• First Name
• Last Name
• Full Name
• Username (SamAccountName)
• User Logon Name (UPN)
• Click Next

Set Password & Account Options:

✔ User must change password at next login
✔ Password never expires (Company policy based)
✔ Account enabled


Click Next → Finish

User account is successfully created.




🎯 Best Practice

• Always create users inside the correct OU to ensure:
• Proper Group Policy application
• Security compliance
• Automatic script execution (if configured)

✅ Step 2 — Add User to Security Groups

After account creation, assign access based on job role.

Most Used Method:

• Right-click User
• Select Properties
• Go to Member Of tab

You may see default group:

Name            | Location
-----------------------------------
Domain Users    | test.com/Users
To Add User to Required Groups:

Click Add

• Enter group name (e.g., VPN_Users, Email_Users, Finance_Share)
• Click Check Names
• Click OK
• Click Apply
• Typical Groups Assigned:
• Email Access Group
• VPN Access Group
• File Server Access Group
• Printer Access Group
• Department Security Group

💬 Professional Interview Answer Line

“I will open ADUC using dsa.msc, navigate to the appropriate OU, create a new user via New → User, configure password policies, enable the account, and assign necessary security groups through the Member Of tab to provide email, VPN, file, and printer access based on the user’s role.”

✅ Step 3 — Inform Microsoft 365 Admin (Hybrid Environment)

• If organization uses Hybrid AD setup:
• User account syncs via:
• Azure AD Connect

Process:

• Wait for Azure Sync cycle
• Verify user appears in Microsoft 365 Admin Center
• License will be assigned by M365 Admin team
• Once license is assigned:
• Mailbox gets provisioned
• Teams access enabled
• OneDrive created

🔍 Verification Steps After Sync

• Check user appears in Microsoft 365 portal
• Confirm license assigned
• Verify mailbox created in Exchange Online
• Confirm Teams login works

🚨 Step 4 — Escalation Criteria

• Escalate to L2 / Cloud Admin if:
• User not syncing to Azure AD
• Sync errors in Azure AD Connect
• No mailbox created after license assignment
• Duplicate UPN conflict
• Azure AD provisioning issue

Before escalation, document:

• OU location
• Groups assigned
• Time of account creation
• Sync cycle time
• Error screenshot (if any)

📝 Real Helpdesk Documentation Format

Request: New User Creation – Finance Department
Action Taken:
Created user in AD → Assigned groups → Confirmed sync → Informed M365 admin

Pending: License assignment
Status: Awaiting mailbox provisioning

🔐 L1 Best Practices

• ✔ Always verify HR approval before account creation
• ✔ Follow naming convention standard
• ✔ Assign minimum required permissions (Least Privilege Principle)
• ✔ Confirm department-specific groups
• ✔ Document everything in ticket

✅ Quick Checklist Summary

• ✔ Create user in correct OU
• ✔ Set password policy
• ✔ Enable account
• ✔ Add required groups
• ✔ Wait for Azure sync
• ✔ Inform M365 Admin
• ✔ Verify mailbox creation

Disclaimer

Microsoft-365-L1-Desktop-Support-guide

This article is designed as a practical, In enterprise environments, users are organized in Organizational Units (OUs) within Active Directory to apply department-based policies, security controls, and access permissions. When an employee changes department, role, or location, moving the user to the correct OU becomes an essential L1 support task.

Improper OU placement can result in login issues, incorrect Group Policy Objects (GPOs), missing permissions, or security misconfiguration. This guide explains the standard L1 workflow for safely moving users between OUs.

I will write article on each topic for single single blog -

I’ll break into real helpdesk categories:

1. Unlock user
2. Reset password
3. Enable / Disable account
4. Create new user
5. Add user to group
6. Remove user from group
7. Check login issues
8. Move user to correct OU
9. Basic permission via groups

Today we will see step by step Account & License Management  

📂 SCENARIO — Move User to Correct Organizational Unit (OU)

 Here is your complete structured blog article content for the title:



🔎 When Is This Required?

• This action is typically performed when:
• Employee department changed (e.g., Sales → IT)
• Role or designation updated
• Location transfer (Branch change)
• GPO policy needs to be updated
• Access level needs to align with new department
• Incorrect OU placement during user creation

1️⃣ Step 1 — Verify Authorization

• Before moving the user:
• Confirm HR approval or official department change email
• Ensure service request/ticket is raised
• Verify new department details
• Confirm correct destination OU name
• ⚠ Never move users without documented approval. OU structure affects security policies.

2️⃣ Step 2 — L1 Action (Move User in ADUC)

🖥 Using Active Directory Users and Computers (ADUC)
 

Method 1 — Drag & Drop (Most Common)

 

• Open ADUC
• Locate the current OU (e.g., Sales)
• Find the user account
• Drag and drop the user into the new OU
• Example:
• Sales → IT Department OU
• Confirm the move

Method 2 — Right-Click Move Option

• Open ADUC
• Right-click the user
• Select Move
• Choose the correct destination OU
• Click OK
• This method is safer when OU hierarchy is complex.

< br />

3️⃣ Post-Move Validation

• After moving the user:
• Run gpupdate /force on user machine (if required)
• Ask user to log off and log back in
• Verify:
• Folder access
• Application access
• Network drive mapping
• Printer access
• Confirm Outlook and VPN working properly
• GPO policies may take time depending on replication and site configuration.

4️⃣ Common Issues After OU Move

• Sometimes after moving a user:
• Login takes longer (GPO processing)
• Access to previous department resources removed
• New drives not mapping
• Restrictions applied due to tighter policies
• MFA / conditional access behavior changes (hybrid setup)
• Always inform user about possible policy refresh delay.

🚨 Escalate If

• Escalate to L2 / AD Team if:
• User cannot login after OU move
• GPO not applying properly
• Access conflicts occur
• Replication issues between Domain Controllers
• Hybrid sync issue (Azure AD Connect)
• OU protected from accidental deletion and move fails
• 🧠 Real Helpdesk Insight

OUs are often linked to:

• Group Policy Objects (GPOs)
• Login scripts
• Security baselines
• Software deployment policies
• BitLocker / Endpoint policies
• Moving a user changes all applied policies. Always double-check the destination OU.

✅ L1 Checklist (SOP Style)

• ✔ HR/Manager approval verified
• ✔ Ticket logged
• ✔ Correct OU identified
• ✔ User moved via ADUC
• ✔ GPO refresh completed
• ✔ User login tested
• ✔ Access validated
• ✔ Escalated if required

🎯 Interview-Ready Answer

If interviewer asks how you move a user to a different department:

“First, I verify HR approval and the correct target OU. Then I use ADUC to move the user either via drag-and-drop or the Move option. After the move, I ensure Group Policy refresh and validate that the user has appropriate access based on the new department. If GPO or replication issues occur, I escalate accordingly.”

Disclaimer

Microsoft-365-L1-Desktop-Support-guide

This article is designed as a practical, Access-related issues are among the most common tickets handled by L1 Desktop Support. In most enterprise environments, access to shared folders, printers, and network resources is controlled through Active Directory Security Groups rather than individual user permissions.

This guide explains how L1 engineers should verify and manage basic permissions using AD groups before escalating.

I will write article on each topic for single single blog -

I’ll break into real helpdesk categories:

1. Unlock user
2. Reset password
3. Enable / Disable account
4. Create new user
5. Add user to group
6. Remove user from group
7. Check login issues
8. Move user to correct OU
9. Basic permission via groups

Today we will see step by step Account & License Management  

👥 SCENARIO — User Cannot Access Folder / Printer

 


🔎 Symptoms Observed


Users typically report:

• “Access Denied” while opening shared folder
• Unable to see mapped network drive
• Printer not visible or cannot print
• Shared drive missing after department change
• Application access denied

🎯 Root Cause (Common)

• In most cases, the issue is due to:
• User not added to correct Security Group
• User moved to new department but groups not updated
• Recent account creation without proper group membership
• Group membership change not refreshed

1️⃣ Step 1 — Verify User Group Membership

🖥 Using Active Directory Users and Computers (ADUC)

• Open ADUC
• Locate the affected user
• Right-click → Properties
• Go to Member Of tab
• Check if correct Security Group is listed

Example:

• Finance_Share_RW
• IT_Printer_Access
• Sales_NetworkDrive
• If group is missing → proceed to add.

2️⃣ Step 2 — Add User to Correct Security Group

• If access is confirmed via group-based model:
• In Member Of tab → Click Add
• Enter Group Name
• Click Check Names
• Click OK
• Apply → OK
• Always confirm exact group name before adding. Avoid guessing.

3️⃣ Step 3 — Inform User (Policy Refresh)

• After adding user to group:
• User must:
• Log out and log back in
• Or run gpupdate /force (if required)
• Restart system if necessary
• For printer issues:
• Remove and re-add printer
• Refresh print spooler if required
• Group membership changes require session refresh to apply new token permissions.

4️⃣ Important Understanding (Token Refresh Concept)

• When a user logs in, Windows generates a security token containing group memberships.
• If you add a group:
• It will not apply until next login session
• VPN users must reconnect
• RDP sessions may require restart
• This is a key concept in AD-based permission management.

🚨 Escalate If

• Escalate to L2 / Server Team if:
• NTFS permissions missing on folder
• Share permissions incorrectly configured
• Server-level restriction issue
• DFS replication issue
• Printer server permission problem
• Group exists but not granting access
• L1 should only manage group membership, not modify server NTFS permissions unless authorized
• 🧠 Real Helpdesk Insight

Best practice in enterprises:


❌ Do NOT assign permissions directly to users
✔ Always assign permissions to groups
✔ Add users to groups

This follows the AGDLP Model:

Accounts → Global Groups → Domain Local Groups → Permissions

Understanding this model makes you stronger in interviews.

✅ L1 Checklist (SOP Format)

• ✔ Ticket verified
• ✔ Resource name confirmed
• ✔ Correct group identified
• ✔ User group membership checked
• ✔ User added to group
• ✔ User re-logged
• ✔ Access tested
• ✔ Escalated if NTFS issue

🎯 Interview-Ready Answer

If interviewer asks how you handle folder access issues:

“First, I verify whether access is group-based. I check the user’s group membership in ADUC under the Member Of tab. If the required security group is missing, I add the user to the correct group and ask them to log out and log back in for token refresh. If the issue persists and appears to be an NTFS or server-level permission problem, I escalate to the server team.”

Disclaimer

Microsoft-365-L1-Desktop-Support-guide

This article is designed as a practical, In enterprise environments, user account lockouts are one of the most common tickets handled by L1 Desktop Support teams. These issues typically occur due to multiple incorrect password attempts, expired credentials, VPN authentication failures, or cached password mismatches. As an L1 engineer, your responsibility is to perform proper user verification, validate the account status in Active Directory Users and Computers (ADUC), and resolve the issue without causing security risks. This guide explains the standard real-world workflow followed in IT helpdesk environments.

I will write article on each topic for single single blog -

I’ll break into real helpdesk categories:

1. Unlock user
2. Reset password
3. Enable / Disable account
4. Create new user
5. Add user to group
6. Remove user from group
7. Check login issues
8. Move user to correct OU
9. Basic permission via groups

Today we will see step by step Account & License Management  

👤 SCENARIO 1 — User Account Locked

 

✅ Step 1 — User Verification (Call / Ticket Triage)



Before accessing Active Directory, gather clear information from the user.


Ask the following:

• What exact error message are you receiving?
• Are you seeing “Account Locked” or “Incorrect Password”?
• Since when did the issue start?
• Are you trying to login to:
• Windows domain login?
• VPN?
• Outlook / Microsoft 365?
• Did you recently change your password?
• Are you logged into multiple devices (laptop + mobile)?

🎯 Objective:

• Confirm whether this is:
• A simple password mistake
• A cached credential issue
• A real domain account lockout

✅ Step 2 — Initial L1 Check in Active Directory

Now verify the account status.

Navigate to:

Tools → Active Directory Users and Computers (ADUC)
(Available on Domain Controller or Admin machine with RSAT tools installed)

Steps:

Search for the user account.

Right-click on the user.

Select Properties.

Check the Following:

✔ Is the account locked?
✔ Is the account disabled?
✔ Is the password expired?
✔ Check Account expiration date

✅ Step 3 — Troubleshooting & Resolution

If the account is locked:

Go to:

Right-click User → Properties → Account Tab

Perform Required Action:

✔ Tick Unlock Account
✔ Click Apply / OK

If password reset is required:

✔ Click Reset Password
✔ Set temporary password
✔ Select User must change password at next logon



⚠ Important Best Practice:


Always confirm user identity before resetting passwords (Employee ID / Manager confirmation / Ticket validation).

• 🔎 Additional Checks (If Required)
• If the account locks again immediately:
• Check if user is connected to VPN.
• Ask user to log out from mobile email apps.
• Clear cached credentials in Windows Credential Manager.
• Check mapped drives using old password.
• Verify scheduled tasks running under old credentials.
• Repeated lockouts often indicate:
• Background service using outdated password
• Mobile device syncing with old password
• Stored credentials on another machine

🚨 Step 4 — Escalation Criteria

• Escalate to L2 / AD Team if:
• Account locks repeatedly within minutes
• Possible brute force attack suspected
• Multiple failed login attempts from unknown IP
• Domain Controller replication issue
• Security policy conflict
• Account locked across multiple domain controllers
• Document before escalation:
• Time of unlock
• Event Viewer logs (if checked)
• Number of failed attempts
• User device details

📝 Real Helpdesk Documentation Format Example

Issue: User unable to login – Account Locked
Root Cause: Multiple incorrect password attempts
Action Taken: Verified identity → Unlocked account in AD → Reset password → Advised password change

Status: Resolved

🎯 L1 Engineer Interview Tip

If asked: “How do you handle a locked user account?”


You can say:

“First, I verify the issue with the user and confirm the error message. Then I check the account status in Active Directory Users and Computers. If the account is locked, I unlock it under the Account tab and reset the password if necessary. If the account locks again, I investigate possible cached credentials or background authentication attempts. If it appears to be a security concern or domain issue, I escalate to L2.”

✅ Quick Checklist Summary

✔ Verify user
✔ Check ADUC
✔ Unlock account
✔ Reset password if required
✔ Monitor repeated lockouts
✔ Escalate if suspicious

Disclaimer

Microsoft-365-L1-Desktop-Support-guide

This article is designed as a practical, in enterprise environments, user account lockouts are one of the most common tickets handled by L1 Desktop Support teams. These issues typically occur due to multiple incorrect password attempts, expired credentials, VPN authentication failures, or cached password mismatches. As an L1 engineer, your responsibility is to perform proper user verification, validate the account status in Active Directory Users and Computers (ADUC), and resolve the issue without causing security risks. This guide explains the standard real-world workflow followed in IT helpdesk environments.

I will write article on each topic for single single blog -

I’ll break into real helpdesk categories:

1. Unlock user
2. Reset password
3. Enable / Disable account
4. Create new user
5. Add user to group
6. Remove user from group
7. Check login issues
8. Move user to correct OU
9. Basic permission via groups

Today we will see step by step Account & License Management  

👤 SCENARIO 1 — User Account Locked

✅ Step 1 — User Verification (Call / Ticket Triage)



Before accessing Active Directory, gather clear information from the user.

Ask the following:

• What exact error message are you receiving?
• Are you seeing “Account Locked” or “Incorrect Password”?
• Since when did the issue start?
• Are you trying to login to:
• Windows domain login?
• VPN?
• Outlook / Microsoft 365?
• Did you recently change your password?
• Are you logged into multiple devices (laptop + mobile)?

🎯 Objective:

• Confirm whether this is:
• A simple password mistake
• A cached credential issue
• A real domain account lockout

✅ Step 2 — Initial L1 Check in Active Directory

Now verify the account status.

Navigate to:

Tools → Active Directory Users and Computers (ADUC)
(Available on Domain Controller or Admin machine with RSAT tools installed)

Steps:

• Search for the user account.
• Right-click on the user.
• Select Properties.

Check the Following:

• ✔ Is the account locked?
• ✔ Is the account disabled?
• ✔ Is the password expired?
• ✔ Check Account expiration date

✅ Step 3 — Troubleshooting & Resolution

If the account is locked:

Go to:

Right-click User → Properties → Account Tab

Perform Required Action:

✔ Tick Unlock Account
✔ Click Apply / OK

If password reset is required:

✔ Click Reset Password
✔ Set temporary password
✔ Select User must change password at next logon

⚠ Important Best Practice:

Always confirm user identity before resetting passwords (Employee ID / Manager confirmation / Ticket validation).

🔎 Additional Checks (If Required)

• If the account locks again immediately:
• Check if user is connected to VPN.
• Ask user to log out from mobile email apps.
• Clear cached credentials in Windows Credential Manager.
• Check mapped drives using old password.
• Verify scheduled tasks running under old credentials.
• Repeated lockouts often indicate:
• Background service using outdated password
• Mobile device syncing with old password
• Stored credentials on another machine

🚨 Step 4 — Escalation Criteria

• Escalate to L2 / AD Team if:
• Account locks repeatedly within minutes
• Possible brute force attack suspected
• Multiple failed login attempts from unknown IP
• Domain Controller replication issue
• Security policy conflict
• Account locked across multiple domain controllers
• Document before escalation:
• Time of unlock
• Event Viewer logs (if checked)
• Number of failed attempts
• User device details

📝 Real Helpdesk Documentation Format Example

Issue: User unable to login – Account Locked
Root Cause: Multiple incorrect password attempts
Action Taken: Verified identity → Unlocked account in AD → Reset password → Advised password change
Status: Resolved

🎯 L1 Engineer Interview Tip

If asked: “How do you handle a locked user account?”


You can say:

“First, I verify the issue with the user and confirm the error message. Then I check the account status in Active Directory Users and Computers. If the account is locked, I unlock it under the Account tab and reset the password if necessary. If the account locks again, I investigate possible cached credentials or background authentication attempts. If it appears to be a security concern or domain issue, I escalate to L2.”

Disclaimer

A certificate signing request (CSR) is one of the first steps towards getting your own SSL/TLS certificate. Generated on the same server you plan to install the certificate on, the CSR contains information (e.g. common name, organization, country) the Certificate Authority (CA) will use to create your certificate.



This website explores CVE-2022-26923, a vulnerability in Microsoft's Active Directory Certificate Service (AD CS) that allows any AD user to escalate their privileges to Domain Admin in a single hop!.

A brief look at certificate templates

Windows Active Directory (AD) is not just for identity and access management but provides a significant amount of services to help you run and manage your organisation. Many of these services are less commonly known or used, meaning they are often overlooked when security hardening is performed. One of these services is the Active Directory Certificate Services (AD CS).

When talking about certificates, we usually only think about the most common ones, such as those used to upgrade website traffic to HTTPS. But these are generally only used for applications that the organisation exposes to the internet. What about all those applications running on the internal network? Do we now have to give them internet access to allow them to request a certificate from a trusted Certificate Authority (CA)? Well, not really. Cue AD CS.

AD CS is Microsoft's Public Key Infrastructure (PKI) implementation. Since AD provides a level of trust in an organisation, it can be used as a CA to prove and delegate trust. AD CS is used for several things, such as encrypting file systems, creating and verifying digital signatures, and even user authentication, making it a promising avenue for attackers. What makes it an even more dangerous attack vector, is that certificates can survive credential rotation, meaning even if a compromised account's password is reset, that will do nothing to invalidate the maliciously generated certificate, providing persistent credential theft for up to 10 years! The diagram below shows what the flow for certificate requests and generation looks like.

Since AD CS is such a privileged function, it normally runs on selected domain controllers. Meaning normal users can't really interact with the service directly. On the other side, organisations tend to be too large to have an administrator create and distribute each certificate manually. This is where certificate templates come in. Administrators of AD CS can create several templates that can allow any user with the relevant permissions to request a certificate themselves. These templates have parameters that say which user can request the certificate and what is required. What SpecterOps has found, was that specific combinations of these parameters can be incredibly toxic and be abused for privilege escalation and persistent access!



Before we dive deeper into certificate abuse, some terminology:

• PKI - Public Key Infrastructure is a system that manages certificates and public key encryption
• AD CS - Active Directory Certificate Services is Microsoft's PKI implementation which usually runs on domain controllers
• CA - Certificate Authority is a PKI that issues certificates
• Certificate Template - a collection of settings and policies that defines how and when a certificate may be issued by a CA
• CSR - Certificate Signing Request is a message sent to a CA to request a signed certificate
• EKU - Extended/Enhanced Key Usage are object identifiers that define how a generated certificate may be used

1) What does the user create to ask the CA for a certificate?

Ans :- Certificate Signing Request



2) What is the name of Microsoft's PKI implementation?

Ans :- Active Directory Certificate Services

Client Authentication

As discussed in the overview of Certificate Templates, they are convenient to allow users and systems to enrol for certificates. Certificates have many use cases in the network. For CVE-2022-26923 and the template misconfigurations discovered by SpectorOps, the primary focus is on the Client Authentication use case.


Client Authentication allows the owner of the certificate to use it to verify their own identity in AD for authentication purposes. For example, a client certificate is used to authenticate against a web application. The authentication process occurs through Kerberos. If we have a valid certificate that has the Client Authentication EKU, we can interface with AD CS and the Key Distribution Centre to request a Kerberos TGT that can then be used for further authentication.


As an attacker, we can leverage this to generate a TGT to impersonate another user or system, should we have a valid certificate for them. In essence, we want to be able to modify the Subject Alternative Name (SAN) attribute of the certificate request to point to someone or something else, that has more permissions to perform privilege escalation.

Default Certificate Templates

By default, when AD CS is installed in an environment, two certificate templates are made available for requests that support Client Authentication:


User Certificate Template - This certificate template can be requested by any user that belongs to the Domain Users group.

Machine Certificate Template - This certificate template can be requested by any host that belongs to the Domain Computers group.



The User Template is not vulnerable by default. When we request a certificate based on the User template, the User Principal Name (UPNs) of the user account will be embedded in the SAN that can be used for identification. Since UPNs must be unique, and we usually do not have the ability to modify our UPN, we cannot leverage this template. Furthermore, since we don't have the ability to alter the SAN value in the certificate signing request, we cannot impersonate another user by specifying their UPN.


However, computer accounts do not have a UPN. Instead of using a UPN for authentication, the Machine template uses the DNS Name of the machine for identification and authentication. When a certificate is requested for a machine through the Machine template, AD CS embeds the machine's DNS Name into the SAN, which is then used for authentication.

Default Domain User Privileges

By default, any user who is a member of the Authenticated Users group (literally all AD accounts) can enrol up to 10 new machines on the domain. This is often used in organisations to allow users to bring their own device (BYOD) and enrol it for use on the domain. This in itself is not really a vulnerability but has led to some interesting privilege escalation vectors in the path, exactly what we will be exploiting for this CVE.


When we enrol a new host in AD, we are assigned as the owner of that host. This provides us with certain permissions over the AD Object associated with that host. Two permissions in particular cause an issue here:


Validate write to DNS hostname - This permission allows us to update the DNS hostname of our AD Object associated with the host.

Validate write to Service Principal Name (SPN) - This permission allows us to update the SPN of our AD Object associated with the host.


SPNs are used by Kerberos authentication to associate a service instance with a service logon account. By default, the Computer AD Object receives SPNs associated with their name to allow for Kerberos authentication, which the host requires to perform specific requests against AD. SPNs must be unique, meaning two AD Objects are not allowed to have the same SPN.


You would think it would be as simple as changing the DNS hostname to another hostname, maybe the hostname of a Domain Controller for privilege escalation? However, if you change the DNS hostname, Microsoft automatically updates the SPN attribute. Since those must be unique, we will get an error if we try to impersonate another host through the DNS hostname attribute. But since we have the ability also to change the SPN, we can bypass this restriction.


The pieces of the puzzle should now start to come together. If we only had one of the two permissions, we would not have a vulnerability.  However, the combination of having those two permissions allows us to perform privilege escalation.

Putting it all Together

Using these configurations, the default AD CS Machine certificate template, the default ability to enrol a new machine, and the default permissions assigned on the created Computer AD Object, we have a privilege escalation vector on our hands. What makes it worse is that this privilege escalation vector requires minimal effort, meaning the attacker's skill level to exploit this issue is quite low. The basic steps are the following:

1. Compromise the credentials of a low-privileged AD user.
2. Use those credentials to enrol a new host on the domain.
3. Alter the DNS hostname attribute of the Computer AD Object to that of a privileged host, such as a Domain Controller.
4. Remove the SPN attributed to bypass the unique SPN conflict issue.
5. Request a Machine certificate using the default template.
6. Perform Kerberos authentication with the received template, now as the privileged machine account instead of our fake machine account.

   
   



1) Which EKU allows us to use the generated certificate for Kerberos authentication?

Ans :- Client Authentication



2) What AD group can request a certificate using the Machine Certificate Template?

Ans :- Domain Controller



3) What value in the Machine Certificate is used for identification and authentication?

Ans :- DNS Hostname

To Be Continue....Exploitation soon

Disclaimer

Critical samba bug lurking in your system CVE-2021-44141 and CVE-2022-0336

Understanding SMB

SMB - Server Message Block Protocol - is a client-server communication protocol used for sharing access to files, printers, serial ports and other resources on a network. [source] Learn about, then enumerate and exploit a variety of network services and misconfigurations.
 
Servers make file systems and other resources (printers, named pipes, APIs) available to clients on the network. Client computers may have their own hard disks, but they also want access to the shared file systems and printers on the servers. The SMB protocol is known as a response-request protocol, meaning that it transmits multiple messages between the client and server to establish a connection. Clients connect to servers using TCP/IP (actually NetBIOS over TCP/IP as specified in RFC1001 and RFC1002), NetBEUI or IPX/SPX.

How does SMB work?

Once they have established a connection, clients can then send commands (SMBs) to the server that allow them to access shares, open files, read and write files, and generally do all the sort of things that you want to do with a file system. However, in the case of SMB, these things are done over the network.

Also read- All about SMB and enum4linux with Questions/Answer

Also read- Samba and exploitation too

Samba Active Directory

The Samba AD DC includes checks when adding service principals names (SPNs) to an account to ensure that SPNs do not alias with those already in the database. Some of these checks are able to be bypassed if an account modification re-adds an SPN that was previously present
on that account, such as one added when a computer is joined to a domain. An attacker who has the ability to write to an account can exploit
this to perform a denial-of-service attack by adding an SPN that matches an existing service. Additionally, an attacker who can
intercept traffic can impersonate existing services, resulting in a loss of confidentiality and integrity.




According to the CERT Coordination Center (CERT/CC), the flaw also affects widely used Linux distributions such as Red Hat, SUSE Linux, and Ubuntu.

The vulnerability, rated 9.9 on the CVSS scale, has been credited to security researcher Orange Tsai from DEVCORE, who last year disclosed the widely-exploited flaws in Microsoft Exchange Server. Additionally, the fix has been issued in Samba versions 4.14.12 and 4.15.5.



Samba administrators are advised to upgrade to the latest releases (4.13.17, 4.14.12, and 4.15.5) or apply a patch as soon as possible. Mitigation short of patching would involve changing Samba configuration files so that the vulnerable vfs_fruit module doesn’t run. “The specific flaw exists within the parsing of EA metadata when opening files in SMBD,” an advisory on the flaw from developers of Samba explains.

The ability to write access to extended file attributes is needed in order to attack the flaw, but such permissions are granted to guest or unauthenticated users.

Also addressed by Samba are two additional flaws —

• CVE-2021-44141 (CVSS score: 4.2) - Information leak via symlinks of existence of files or directories outside of the exported share (Fixed in Samba version 4.15.5)
  

• CVE-2022-0336 (CVSS score: 3.1) - Samba AD users with permission to write to an account can impersonate arbitrary services (Fixed in Samba versions 4.13.17, 4.14.12, and 4.15.4)

Samba administrators are recommended to upgrade to these releases or apply the patch as soon as possible to mitigate the defect and thwart any potential attacks exploiting the vulnerability

Disclaimer