Hey all,
We have Windows 10/11 devices that are Azure AD Joined (AADJ) only (not domain joined).
We have Kerberos Cloud Trust setup so that these devices can access on-premises resources without being domain joined.
The caveat is that they need line of sight to a domain controller at logon time for this to work, otherwise when they login they do not receive a TGT (nothing appears in klist).
So anyone who has set this up - how do you do this over a VPN?
The only solution I can think of is a VPN with device tunnels / pre-logon. We’ve got a Fortigate so we can utilise Forticlient but from what I gather, that requires device certificates and checks them against AD (which won’t work because AADJ computer objects won’t exist there). Alternatively there is the Always-on-VPN option which requires Enterprise licensing for device tunnels to work, plus I imagine a fair bit of complexity in getting device certificates issued to computers, and then I imagine AOVPN would also require the devices to exist as AD objects too, right?
Has anyone managed to do something like this or can provide insight into how it may be possible?
I must be missing something if this is the Microsoft recommended way of doing things, but it doesn’t seem to be possible remotely.
(Side note: I haven’t tested, but do they need line-of-sight to a domain controller if they login with password instead of PIN/Biometrics?)
Thanks in advance!
I think you are mistaken. I’ve setup cloud kerberos trust and tested with WHFB on AADJ… No LOS to DC is required at logon. After I connect to VPN post logon, I get SSO to file shares with no issues.
I thought this does work without line of sight to the DC at logon, and the cloud ticket is retrieved from Azure as part of the PRT at logon, and can be upgraded to the full ticket later after connecting to the local network
(i.e.: CloudKerberosTicketRetrievalEnabled set to 1)
Authentication to Active Directory from an Azure AD joined device begins when the user first attempts to use a resource that needs Kerberos authentication.
Source
Unfortunately I no longer work at the place we used this, so I cannot check right now
I had the same issue, but the problem was not the TGT not being issued but the time delay before the issuance. By default, there is a 15 mins timeout after an unsuccessful TGT issuance. To overcome this, I had to reduce the timeout to 1 minute and since then no issues reported.
You can deploy a device script:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" -Name FarKdcTimeout -PropertyType DWORD -Value "1" -Force
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" -Name SpnCacheTimeout -PropertyType DWORD -Value "1" -Force
I just fixed this. I’ll comment the PowerShell code later.
Here is the code I deployed. It creates a scheduled task that runs at login. The task runs klist purge_bind and get krbtgt. Basically, find a domain controller and then get a ticket.
$GetKerberosTickets = {
Remove-Item C:\IT\Kerberos.txt -Force
Start-Transcript -Path C:\IT\Kerberos.txt
Remove-Item $env:TEMP\klist.txt -Force
do{
$datetime = get-date
$tickets = $false
klist *> $env:TEMP\klist.txt
$Klist = get-content -path $env:TEMP\klist.txt
$KlistTest = Select-String -Path "$env:TEMP\klist.txt" -pattern "krbtgt/$env:USERDOMAIN.COM"
Write-Host "$klist"
if($KlistTest -eq $null){
Write-Host "no tickets - $datetime"
C:\Windows\system32\klist.exe purge_bind
Start-Sleep -Seconds 5
C:\Windows\system32\klist.exe get krbtgt
Start-Sleep -Seconds 5
Start-Sleep -Seconds 5
}else{
Write-Host "tickets - $datetime"
$tickets = $true
Remove-Item $env:TEMP\klist.txt -Force
}
}until($tickets -eq $true)
Stop-Transcript
}
Set-Content C:\IT\ScheduledTask\Get-Kerberos-Tickets.ps1 -Value $GetKerberosTickets -Force
$taskname="Get-Kerberos-Tickets"
# delete existing task if it exists
Get-ScheduledTask -TaskName $taskname -ErrorAction SilentlyContinue | Unregister-ScheduledTask -Confirm:$false
# get target script based on current script root
$scriptPath="C:\IT\ScheduledTask\Get-Kerberos-Tickets.ps1"
# create list of triggers, and add logon trigger
$triggers = New-ScheduledTaskTrigger -AtLogOn
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable
# create task
$principal = New-ScheduledTaskPrincipal -GroupId Users -RunLevel Highest
$Action = New-ScheduledTaskAction -Execute "cmd.exe" -Argument '/c start /min "" powershell -WindowStyle Hidden -ExecutionPolicy Bypass -File "C:\IT\ScheduledTask\Get-Kerberos-Tickets.ps1"'
$Task = Register-ScheduledTask -TaskName $taskname -Trigger $triggers -principal $principal -Action $Action -Force -Settings $settings
$task | Set-ScheduledTask
Start-Sleep -Seconds 60
$GetTask = Get-ScheduledTask -TaskName $taskName
if($GetTask.State -eq "Ready"){
Write-Host "$taskname task is $($gettask.State)"
}else{
Write-Host "$taskname task is NOT present. Something went wrong"
}
Our setup is the same with WHfB cloud trust with AOVPN user tunnels configured that connect post logon. We do not have any issues connecting to file shares.
Are you connecting via fqdn or netbios names to the file server? There is a VPN setting you need to modify if pointed to short netbios names. Not sure if Fortigate has something similar?
https://directaccess.richardhicks.com/2021/09/20/always-on-vpn-short-name-access-failure/
Have you seen the video that Intune.Training have one this? There’s some troubleshooting tips towards the end.
https://youtu.be/q0Y4g0dcOY4?si=tlHsM7EW1J4QCr-x
They had an issue where they couldn’t access fileshares when using Hello credentials. Turns out they needed to clear the Hello container and re-register it.
Hey any updates on this? I’m in the same boat.
Im.yrying to access file share with sso and getting the same thing that need to enter username and password
I know exactly what you mean… I haven’t tested it but usually the answer is AOVPN although I would love to hear a more experienced voice on this. Since you are using FortiClient push a pre login VPN from EMS which will allow a manual option or connect at the login screen. Ensure FortiClient 7.0.9
The modern solution without VPNs would be something like this:
https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-private-access
Still in preview with Microsoft.
Acts as an outbound proxy to open up SMB ports and can be used with Conditional Access
Try to deploy the VPN client in the system context … the use can connect from the login screen.
Make sure VPN client is always on and pointing to your DNS server.
Wait I’m a little confused, what exactly is not working here? We haven’t set up cloud kerberos yet and I can access file shares from the VPN on my AADJ device just fine.
Hmmm, yeah in my experience, when they log on without LoS to a DC, then establish a VPN to get LoS, they’re prompted for creds when they try to access something like a file share.
Worth noting that the network drive is mapped from the get go, so maybe the following is happening:
- User logs in without LoS to DC
- Network drive tries to connect without LoS and fails (would this failure clear out the partial TGT maybe?)
- User double clicks on drive, says login failed and prompts for creds
I need to do some manual validation to see what works or doesn’t work with PIN vs Password (maybe it’ll work fine with password but not with WHFB PIN?).
From https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-faq#do-i-need-line-of-sight-to-a-domain-controller-to-use-windows-hello-for-business-cloud-kerberos-trust:
Windows Hello for Business cloud Kerberos trust requires line of sight to a domain controller when: a user signs-in for the first time or unlocks with Windows Hello for Business after provisioning
One solution I’m also looking into is running klist purge_bind then klist get krbtgt after logon (or triggered once VPN connects), but not sure if that’ll work.
I actually saw a similar post so might give that one a shot - I’m wondering if it’s because it tries to connect to the mapped drive immediately after login but before VPN connects, then this fails and causes this 15 minute waiting period. I’ll try this out on Monday when I get the lab setup!
That and running klist purge_bind then klist get krbtgt after logon (or triggered once VPN connects) are the two things I’ll look at!
push a pre login VPN from EMS which will allow a manual option or connect at the login screen
Having not used Forti much before could you explain how this works? How do they authenticate to the VPN before login? Device certificates? Username/Password?
Just don’t want to be in a situation where staff have to remeber to login to the VPN first and then login with a PIN or everything will break haha.
Yes I did see that come out in preview but from what I gather it doesn’t solve the issue of needing line of sight to a domain controller during the login process on the AADJ device, given that the kerberos ticket is required to access the share in the first place, regardless of whether it’s direct LoS to the file share, done over a VPN, or using this Entra Private access ZTNA solution.
The issue is more around line-of-sight to the domain controller (or KDC) for authentication, not line of sight to the file share itself.
What’s not working is single sign-on to said shares.
When they login without line-of-sight to a DC, they don’t get a kerberos ticket, so they are prompted for credentials and have to manually type them in to access any on-prem shares.
Now that you mention it, I do recall one of the techs saying something about users having to use password auth once after we set this stuff up, but after that one password logon then pin would work, though I don’t recall why that was the case.
Just to confirm, you have set the CloudKerberosTicketRetrievalEnabled csp, or equivalent registry / gpo on the clients? I do believe that is required to avoid the credential prompt.
I don’t believe your mapped drive would affect things, since before connecting the VPN it would fail the dns lookup or timeout at tcp, so it should not even try to authenticate.