Let the AI do ALL the work - Run an AI-Operated Employee Lifecycle in My Homelab
From Active Directory to a Real Hybrid Windows Sign-In
How I Used ChatGPT and Codex to Run an AI-Operated Employee Lifecycle in My Homelab
I already had the hybrid Microsoft environment. See my VMware and Server 2025 post for documentation.
Active Directory was running on DC01. Microsoft Entra Connect synchronized a deliberately limited part of the domain into my test tenant. CLIENT01 remained my cloud-only Intune client, while the physical computer STEUERN was my Hybrid Microsoft Entra Join pilot.
So the next question was not really:
Can I create another user?
I already knew how to do that.
The more interesting question was:
What happens if I give an AI administrator access to the lab and tell it what business outcome I want, instead of telling it which buttons to press and which commands to run?
That became this experiment.
I wanted ChatGPT and Codex to provision a fictional employee through the complete hybrid identity chain:
Active Directory
↓
Microsoft Entra Connect
↓
Microsoft Entra ID
↓
Cloud groups and licensing
↓
Hybrid Windows sign-in
↓
Primary Refresh Token
↓
Intune state
The fictional employee was called Mira Testfeld.
The important part was that I did not want this to become another tutorial where I manually copied commands from ChatGPT into PowerShell.
I wanted the AI to inspect the environment, determine how it could administer it, verify that the documented state was still true, perform the provisioning, and prove that the result worked.
And, very importantly, I also wanted to see where it failed.
This is a disposable homelab. None of the systems described here are production systems. Passwords, authentication tokens, recovery keys and other secrets are intentionally not included.
Architecture Overview
The relevant environment already consisted of two network areas.
VLAN10 is my management network. VLAN30 contains the isolated Windows lab environment.
The simplified architecture for this experiment looked like this:
AETHER
Windows 11
192.168.10.101
|
| SSH
v
Test
Ubuntu
192.168.10.123
|
| WinRM
v
DC01
Windows Server 2025
192.168.10.103
192.168.30.1
Active Directory + Entra Connect
|
| WinRM / RDP
v
STEUERN
Physical Windows client
192.168.30.51
Hybrid Microsoft Entra Join
AETHER
|
| HTTPS
v
Microsoft Cloud
Entra + Microsoft 365 + Intune
There were several other systems in the environment, including:
- CLIENT01 at 192.168.30.50, intentionally cloud-only;
- WSUS01 at 192.168.30.20;
- LibreNMS at 192.168.10.5;
- ARES-ESXi at 192.168.10.50.
CLIENT01 was particularly important because it gave the experiment a boundary.
The AI was allowed to work inside the disposable lab, but it was not allowed to accidentally turn my cloud-only test client into another hybrid device.
The Team: Daniel, ChatGPT, and Codex
Just like some of my previous AI-assisted projects, this was effectively a three-part team.
Daniel — meaning me — owned the actual environment and the final decisions.
I knew why CLIENT01 had to remain cloud-only, which parts of the environment were disposable, where I was willing to accept experimental shortcuts, and when the AI was making an assumption that did not match the real lab.
I also supplied access where necessary and remained responsible for deciding whether the result made sense.
ChatGPTClassic acted mainly as the planning and management layer.
We defined the experiment here first. Instead of asking Codex to “create user X with these commands,” the goal was expressed more like a real administrative task:
Provision a fictional employee through the existing hybrid Microsoft environment, verify the result, and do not modify the cloud-only client.
ChatGPT also became the place where the broader project context lived: why the environment had been built this way, which systems served which purpose, and what I wanted to test next.
ChatGPT Work (inside the new ChatGPT app, formerly known as Codex App) became the local execution layer.
This time I deliberately wanted to push that role further.
I did not just want Codex to execute a clearly prepared PowerShell command. I wanted it to determine how to reach the infrastructure in the first place.
The intended workflow therefore looked like this:
Daniel
defines the goal, boundaries and final responsibility
↓
ChatGPT
helps define the experiment and evaluates the approach
↓
Codex
discovers the environment, administers it and collects evidence
↓
Daniel + ChatGPT
review what actually happened
There was one practical complication.
The local Codex/Work session could not simply be started inside the existing ChatGPT project in the way I first expected. So the project conversation remained the planning and documentation layer, while the actual local computer-use session ran separately.
That separation turned out to be fine.
In fact, it made the roles even clearer.
Before Provisioning Anything: Discovery First
The first important decision was that Codex should not immediately create Mira.
It first had to verify the existing environment.
This was important because this lab has evolved over months. Old documentation exists. Chat history exists. IPAM exists. LibreNMS exists.
But none of those automatically proves what is running right now.
So the first phase was read-only discovery.
Codex checked:
- which systems AETHER could reach;
- which management tools were installed;
- whether DC01 was online;
- whether Active Directory could be reached;
- whether the hybrid pilot OUs still existed;
- whether Microsoft Entra Connect was running;
- whether STEUERN was still hybrid joined;
- whether CLIENT01 remained cloud-only;
- which Microsoft administration portals were accessible;
- and which licenses were actually usable.
This was exactly the behavior I wanted.
A running AI with administrator credentials should not treat a six-week-old Markdown file as authoritative infrastructure state.
First Problem: The Infrastructure Was Off
The first discovery attempt ran into a very ordinary homelab problem.
Some of the required machines were powered off.
Codex correctly recognized that DC01 and the rest of the Windows lab were not available.
But this also exposed the first weakness in the experiment.
It asked me to power on ESXi.
I did.
That worked, but it was not really the behavior I wanted from an increasingly autonomous lab administrator.
I already have Wake-on-LAN mechanisms in this environment. The ESXi host has a documented MAC address. STEUERN also has a documented Wake-on-LAN configuration. Codex knows how to turn it on and did even create a script for me so I can do it with a double click from DC01s desktop.
A better agent should ideally reason like this:
DC01 unavailable
↓
DC01 runs on ESXi
↓
ESXi appears to be powered off
↓
Check inventory / runbooks
↓
Wake-on-LAN method exists?
↓
Wake ESXi
↓
Verify that it starts
↓
Continue discovery
Instead, the first escalation point was still:
Please turn the machine on.
So the first lesson appeared before the real experiment had even started:
The AI was cautious, which was good, but still too dependent on the human operator for routine infrastructure recovery.
That is something I want to improve later.
Second Problem: AI Memory Is Not Infrastructure Inventory
The next issue was even more interesting.
During early discovery, Test was associated with the wrong address.
The correct addresses are:
Test 192.168.10.123 LibreNMS 192.168.10.5
That information existed in the broader project history, but it was not reliably available to the local execution session at the moment it needed it.
I corrected Codex.
It then checked the connected IPAM data and verified the environment against the live systems.
The problem sounds trivial. It is just an IP address. Usually ChatGPT knows about the documentations and has access to it. It was kind of a surprise that it did not look into it this time.
This is actually one of the most important results of the whole experiment.
If an AI is supposed to administer infrastructure, important operational facts cannot depend on whether the correct fragment of an old conversation happens to be retrieved.
The correct model should be:
Chat history
= useful context
Documentation
= useful context
IPAM / inventory
= intended source of truth
Live system
= final verification
This immediately created the idea for another future project: building a proper AI-readable operational memory for the homelab. I did not properly set up the agents related files yet!
More on that later.
Step 1: Finding a Working Administration Path
Once the machines were running, Codex had another problem.
AETHER was not actually configured as a traditional Windows administrator workstation.
It had:
- Windows PowerShell 5.1;
- SSH;
- Remote Desktop.
But it did not have:
- the Active Directory PowerShell module;
- Microsoft Graph PowerShell;
- Exchange Online PowerShell;
- PowerShell 7.
The easy solution would have been to install a pile of administrative software on AETHER.
That was not necessary.
Codex discovered that AETHER could reach the Ubuntu machine Test over SSH.
Test already had Python and pywinrm.
DC01 exposed WinRM on TCP 5985.
So Codex assembled this management path:
AETHER | | SSH :22 v Test | | WinRM :5985 | NTLM v DC01
The important part is that the actual Active Directory commands ran on DC01, where the Active Directory and Entra Connect modules already existed.
AETHER did not need to become a giant administration workstation just to make the experiment work.
I liked this result because it felt much more like actual infrastructure work.
The environment was not pre-arranged for the AI.
It had to discover a viable control path from what already existed.
Step 2: Verifying Active Directory and Entra Connect
With a working path to DC01, Codex could finally inspect the hybrid environment properly.
The live Active Directory configuration confirmed:
Forest: int.acme.com Domain: int.acme.com NetBIOS: ACME DC: DC01
The intended pilot OUs also existed:
ACME
├── Users
│ └── Hybrid-Pilot
│
└── Workstations
└── Hybrid-Pilot
Those OUs matter because I intentionally did not want to synchronize the whole lab into Entra ID.
Microsoft Entra Connect was running on DC01.
The live configuration showed:
- Microsoft Entra Connect 2.6.84.0;
- Password Hash Sync enabled;
- automatic synchronization enabled;
- a 30-minute synchronization cycle;
- user synchronization restricted to the Hybrid-Pilot users OU;
- device synchronization restricted to the Hybrid-Pilot workstations OU.
This confirmed that the environment was still behaving like the pilot I originally intended.
Codex also discovered something that made the documentation more precise.
The Hybrid Join configuration was targeted through policy rather than relying on a directory-wide Service Connection Point.
That distinction matters.
It helps explain why STEUERN can be the hybrid pilot while CLIENT01 remains deliberately cloud-only.
Step 3: Verifying the Existing Hybrid Windows Client
Before creating a new employee, the existing hybrid pilot had to work.
That pilot is STEUERN.
From DC01, Codex could reach STEUERN using WinRM.
The live device state confirmed:
DomainJoined : YES AzureAdJoined : YES
Intune also reported STEUERN as:
- corporate owned;
- compliant;
- actively managed.
The existing Hybrid Test User could obtain:
AzureAdPrt : YES
This was important.
It proved that the hybrid path was already working before Mira was introduced.
Otherwise a failed Mira login could have been caused by an existing infrastructure problem instead of the provisioning process.
CLIENT01 was also checked.
It remained cloud-only.
An old disabled CLIENT01 computer object still existed elsewhere in Active Directory, but that historical object did not mean the current CLIENT01 installation had suddenly become domain joined.
Again, live state mattered more than object names.
Step 4: Discovering the Cloud Administration Path
The cloud side used a completely different control plane.
There was no useful local Microsoft Graph or Exchange PowerShell environment on AETHER.
But the Codex in-app browser could operate the Microsoft administration portals once I authenticated the session.
That gave the AI access to:
- Microsoft Entra admin center;
- Microsoft 365 admin center;
- Microsoft Intune admin center;
- Exchange admin center.
So the experiment ended up with a split administrative model:
On-premises SSH + WinRM + PowerShell Cloud Browser + Microsoft admin portals
This is probably more realistic than a demo where one machine conveniently has every PowerShell module, API permission and administrative session already prepared.
Step 5: Checking Licensing Before Creating the Employee
This was another part of the experiment where checking the live environment first paid off.
The tenant did not contain the licensing state I would ideally have wanted for a complete Microsoft 365 employee onboarding. I missed that the Intune trial expired already.
The live state was:
| Product | Status |
|---|---|
| Microsoft Entra Suite Trial | Active |
| Microsoft Intune Trial | Expired 2 August 2026 |
| Exchange / Microsoft 365 productivity license | Not available |
The important point is that Codex did not decide to ignore that and make the UI look complete anyway.
This gave the experiment a useful boundary:
Complete what is technically and administratively valid. Report the rest as blocked.
That is a much better result than pretending a lifecycle succeeded when the required entitlement does not exist.
Step 6: Creating Mira Testfeld
Now the actual employee lifecycle began.
The fictional employee was:
| Name | Mira Testfeld |
| Username | mira.testfeld |
| Department | Hybrid Lab |
| Title | Hybrid Lifecycle Analyst |
| Company | ACME |
| Employee ID | LAB-20260809-001 |
Before creating the object, Codex checked for collisions involving:
- display name;
- sAMAccountName;
- UPN;
- employee ID;
- target distinguished name.
Then it created Mira inside the synchronized Hybrid-Pilot users OU.
The lifecycle steps were:
Create Mira in Active Directory
↓
Enable account
↓
Add to workstation RDP group
↓
Trigger Entra Connect delta sync
↓
Confirm synchronized Entra object
↓
Add to cloud pilot group
↓
Set usage location
↓
Assign valid Entra Suite license
A temporary lab password was used, but it is intentionally not included here.
For automation purposes, change-at-next-logon and normal password expiry were disabled for this fictional account.
That is a lab exception, not a recommendation for normal employee provisioning.
Step 7: Synchronizing Mira to Microsoft Entra ID
After creating the AD account, Codex triggered a Microsoft Entra Connect delta synchronization.
The synchronization completed successfully.
Mira then appeared in Microsoft Entra ID as a synchronized on-premises identity.
This was an important distinction.
I did not want:
Mira in AD + separate Mira manually created in Entra
I wanted:
Mira in AD
↓
Entra Connect
↓
same hybrid identity in Entra
That worked.
Mira was then added to the existing cloud pilot group used by the hybrid experiment.
Step 8: The First Cloud Error Was Actually Useful
The first license assignment did not work.
The reason was simple:
Mira did not yet have a usage location.
Instead of trying random changes, Codex identified the missing field, set the usage location to Germany, and retried the valid license assignment.
The active Microsoft Entra Suite trial was then assigned successfully.
The expired Intune Trial was not assigned.
No Exchange mailbox was created because there was no Exchange-capable Microsoft 365 license available.
So the result was:
Entra Suite ✓ assigned Intune ✗ no valid new-user entitlement available Exchange mailbox ✗ no suitable license available
I actually prefer documenting the experiment this way.
It shows the difference between automation and blind automation.
Step 9: The Real Test Was Not the User Object
At this point, Mira existed in AD and Entra.
But that still did not prove the employee lifecycle.
The real question was:
Can Mira actually sign into the physical hybrid workstation and obtain Microsoft cloud authentication state?
That meant testing a real interactive Windows session on STEUERN.
This introduced another interesting technical problem.
A remote system-context command can confirm machine join state.
But the Primary Refresh Token belongs to the signed-in user context.
So simply running:
dsregcmd /status
remotely as SYSTEM would not prove that Mira had received her own PRT.
A real user-context test was required.
Step 10: Network Segmentation Got in the Way — Correctly
AETHER could not directly RDP into STEUERN.
That was not a malfunction.
The VLAN segmentation was doing its job.
Direct management from VLAN10 to the VLAN30 client was blocked.
DC01, however, could reach STEUERN because DC01 participates in the lab network.
For this one validation, Codex created a temporary RDP relay on DC01. It came up with this by itself.
The relay was intentionally narrow:
- one temporary high TCP port;
- bound to DC01's management-side address;
- accessible only from AETHER's IP;
- forwarded only to STEUERN TCP 3389;
- used only for the interactive validation.
The temporary path looked like this:
AETHER
192.168.10.101
|
| temporary high TCP port
v
DC01
192.168.10.103
|
| RDP 3389
v
STEUERN
192.168.30.51
This is one of the parts I would absolutely treat differently in a production design. However it is fun too watch how Codex does things.
For a temporary and tightly scoped lab test, it provided the user-context session we needed without permanently opening direct management access between the networks.
Step 11: Mira Actually Logged In
The RDP session reached STEUERN.
Windows initially displayed a stale previously used account, so Codex selected Use a different account and supplied the ACME credentials for Mira.
The lab's legal notice appeared and was accepted.
The login succeeded.
Mira's Windows desktop loaded.
At that point we had already proven:
- the AD account worked;
- the password worked;
- the group membership allowed the intended workstation access;
- STEUERN accepted the domain identity;
- the account was not locked out.
But there was still one final piece of evidence I wanted.
What did not work well was that it took really really long. I don't know why but computer use was really slow. I sat there and watched some cartoons while Codex opened the RDP session. Then the window just sat there and Codex seemingly did nothing. Then it entered and confirmed the credentials within 1 second.
Step 12: Primary Refresh Token Confirmed
The decisive test was the user-context dsregcmd result.
For Mira, the relevant state was:
AzureAdJoined : YES DomainJoined : YES AzureAdPrt : YES CloudTgt : YES
That AzureAdPrt : YES result was the finish line for the hybrid identity part of the experiment.
The complete chain was now proven:
Mira created in on-premises Active Directory
↓
Password Hash Sync / Entra Connect
↓
Mira appears in Microsoft Entra ID
↓
Mira signs into domain-joined STEUERN
↓
STEUERN is also Microsoft Entra joined
↓
Mira receives a Primary Refresh Token
↓
Cloud SSO state exists
This was much more meaningful than simply seeing a green user object in an admin portal.
Step 13: Intune Still Reported the Device as Compliant
After the interactive test, Codex returned to Intune.
STEUERN still appeared as:
- corporate owned;
- compliant;
- managed.
The device's existing primary user remained Hybrid Test User.
Codex deliberately did not reassign that field to Mira just to make the experiment look cleaner.
That would have been especially questionable because Mira did not have a valid new Intune entitlement.
This was another good example of preserving the actual state instead of optimizing for screenshots.
Step 14: Cleaning Up the Temporary Access
A temporary firewall rule is only temporary if someone removes it.
So cleanup became part of the test rather than an afterthought.
Codex removed:
- the temporary RDP relay;
- the temporary DC01 firewall rule;
- the RDP client session;
- temporary scheduled tasks used for validation;
- temporary output files;
- the temporary test credential stored for the relay connection;
- helper and diagnostic files created during the workflow.
Afterward it verified that the temporary relay port was closed.
It also confirmed that direct AETHER-to-STEUERN RDP was still blocked.
So the final network state returned to:
AETHER → temporary DC01 relay CLOSED AETHER → direct STEUERN RDP BLOCKED
That verification matters to me.
“I ran the delete command” is weaker evidence than “I checked that the temporary service is actually gone.”
Validation Evidence
The final lifecycle state looked like this:
| Lifecycle stage | Result |
|---|---|
| On-premises AD account creation | Passed |
| Password Hash Sync / Entra object creation | Passed |
| Cloud pilot group membership | Passed |
| Active cloud license assignment | Passed |
| Hybrid Windows sign-in | Passed |
| User-context Primary Refresh Token | Passed |
| Existing Intune compliance state | Passed |
| New-user Intune entitlement | Blocked by expired trial |
| Exchange Online mailbox | Blocked because no suitable license exists |
| CLIENT01 remains cloud-only | Passed |
| Temporary access cleanup | Passed |
The important part is that “blocked” and “failed” are not the same thing.
The experiment did not fail because it could not create an Exchange mailbox without an Exchange license.
The correct administrative behavior was to identify the missing entitlement and stop there.
What Codex Did Well
The most impressive part was not any individual command.
It was that Codex managed to work across several different control planes:
- SSH;
- Ubuntu;
- Python WinRM;
- Windows PowerShell;
- Active Directory;
- Microsoft Entra Connect;
- Windows WinRM;
- RDP;
- Microsoft Entra;
- Microsoft 365;
- Microsoft Intune.
It also did several things I consider important for trustworthy administration:
- performed discovery before making changes;
- checked for object collisions;
- verified synchronization rather than assuming it;
- distinguished machine-context join state from user-context PRT state;
- did not assign an expired license merely to complete a checklist;
- did not create a mailbox without a valid entitlement;
- preserved CLIENT01's cloud-only design;
- removed temporary access after use;
- verified that cleanup succeeded.
That is much closer to administrator behavior than simply producing PowerShell commands.
What Codex Did Not Do Well
This project was also useful because it showed some weaknesses very clearly.
It escalated to me too early
When the virtualization infrastructure was powered off, Codex asked me to turn it on.
That was safe.
But the environment already contains management information and Wake-on-LAN mechanisms.
A better autonomous agent should first ask itself:
Do I already have a documented way to fix this?
Only after exhausting those options should it ask the human.
It did not reliably know facts that had already been discussed
The Test versus LibreNMS address confusion is the clearest example.
The fact existed somewhere in the accumulated project history.
But the local execution session did not reliably retrieve it.
That is not acceptable as the long-term memory model for infrastructure administration.
It still depended on broad administrative access
The experiment used existing lab administrative credentials and a signed-in Global Administrator browser session.
That is fine for proving the concept in a disposable environment.
It is not how I would want recurring production automation to operate.
A mature version would use:
- dedicated automation identities;
- least privilege;
- auditable API permissions;
- a proper credential vault;
- clear separation between AD, endpoint and cloud permissions.
Why This Is More Than “AI Created an AD User”
The final PowerShell operation that creates a user is probably one of the least interesting parts of this entire project.
The real workflow was:
Understand the goal
↓
Discover the available systems
↓
Find a management path
↓
Verify the current infrastructure
↓
Check synchronization scope
↓
Check cloud access
↓
Check licensing
↓
Create the identity
↓
Synchronize it
↓
Assign legitimate cloud resources
↓
Perform a real hybrid Windows login
↓
Verify the user's PRT
↓
Check endpoint state
↓
Clean up temporary access
↓
Verify cleanup
That is the interesting part of AI-assisted administration to me.
Writing commands is useful.
But actual administration is mostly about state, dependencies, constraints, validation and judgment.
This experiment forced the AI to deal with all of them.
Lessons Learned
The first lesson is that discovery must come before automation.
If Codex had simply trusted the documentation and started provisioning, it would have been working from stale information before the first user object even existed.
The second lesson is that AI memory and operational state are different things.
Chat history can explain why something exists.
It should not be the canonical database for which host owns 192.168.10.123.
The third lesson is that an AI administrator needs escalation rules.
“System is off, ask Daniel” is safe but inefficient.
A better sequence is:
Problem detected
↓
Check inventory
↓
Check runbook
↓
Try approved recovery method
↓
Verify result
↓
Escalate only if needed
The fourth lesson is that automation should be allowed to say no.
No valid Intune license means no valid new-user Intune assignment.
No Exchange entitlement means no mailbox.
An agent that lies about success is worse than one that reports an incomplete lifecycle.
The fifth lesson is still the same one that keeps appearing in my AI-assisted projects:
AI becomes most useful when it has a defined role, while the human keeps responsibility for the environment and validates the important decisions.
The Next Rabbit Hole: Giving the AI a Real Memory
The most obvious follow-up would be to renew the Microsoft licensing and continue the employee lifecycle.
That would allow me to test:
- a valid Intune user entitlement;
- user-scoped Intune configuration;
- application deployment;
- Conditional Access;
- Exchange Online mailbox provisioning;
- and finally complete employee offboarding.
But another project now interests me even more.
How do I make ChatGPT and Codex reliably know my infrastructure?
Not “remember some things from old conversations.”
I mean a proper operational memory.
Something like:
homelab/
│
├── inventory/
│ ├── hosts.yaml
│ ├── networks.yaml
│ ├── services.yaml
│ └── devices.yaml
│
├── identity/
│ ├── active-directory.md
│ ├── entra.md
│ └── intune.md
│
├── runbooks/
│ ├── wake-on-lan.md
│ ├── esxi.md
│ └── troubleshooting.md
│
└── state/
└── current-state.md
Then an AI administrator could be instructed to always:
read canonical inventory
↓
check current state
↓
look for an existing runbook
↓
perform the approved operation
↓
verify the result
↓
update the operational state
Credentials should eventually live separately in a proper secret store, with the inventory containing only references to them.
The final test would be opening a completely new AI administration session with almost no conversation context and saying:
DC01 appears to be offline. Investigate the problem and continue the hybrid Microsoft lab without asking me to perform routine administration.
If the agent can then independently discover:
DC01 runs on ARES-ESXi
↓
ARES appears offline
↓
Wake-on-LAN is documented
↓
wake ARES
↓
verify ESXi
↓
verify DC01
↓
find Test at 192.168.10.123
↓
retrieve the approved management method
↓
continue the Microsoft lab
then we will have moved one step closer from “AI that can use my computer” toward something much more interesting:
an AI that can actually operate my homelab with context, procedures and accountability.
Final Result
The employee lifecycle was not 100 percent complete because the necessary Microsoft licensing was not available.
But the most important technical chain worked:
Active Directory account
↓
Microsoft Entra synchronization
↓
cloud identity
↓
physical hybrid Windows sign-in
↓
AzureAdPrt = YES
↓
existing Intune compliance confirmed
Mira Testfeld became a real synchronized hybrid identity and successfully signed into the physical pilot workstation.
Codex also respected the cloud-only CLIENT01 boundary and removed the temporary network access it created for validation.
So the experiment answered the original question reasonably well.
Can an AI administer a hybrid Microsoft homelab?
Yes — but the interesting problems are no longer whether it knows the PowerShell syntax.
The difficult problems are knowing which information to trust, discovering how to reach the environment, deciding when not to make a change, recovering from missing infrastructure, managing credentials safely, and proving that the final state is actually correct.
That is exactly why I want to keep pushing these experiments further.