This message was deleted.
# citrix-vad
s
This message was deleted.
l
I don't know but I'm interested.
n
I've got tickets with both MS and Citrix open, so hopefully we can figure it out. MS is just going to blame Citrix now... not that they are ever really helpful, anyway.
l
it's a weird one, may take a while to find the right person to nail it down. Let me know how you get on though.
n
Will do, and I'll post the fix here in case it helps somebody else down the road,.
h
@Julian Jakob also got a blog around this I believe: Citrix FAS - Azure AD CBA with Primary Refresh Token (PRT) (julianjakob.com) perhaps some references there.
n
Yeah, came across that article and am asking the guys who manage FAS if this is configured correctly now.
✅ 1
d
yea i mean everytime i looked into this exact same issue, the solution was to use Azure CBA. Something about when using azure ad as identity provider, it does not send all the info required for the PRT. That's where Azure CBA comes in and fils in the missing parts to get the PRT. My organization was refusing to use Azure CBA so I just make sure our server 2019 VDA's do not hybrid join. if they are not on hybrid then auth works fine as it falls back on seamless SSO. I've have threads here in the past with this issue, not skilled enough in slack to find them lol.
happy to help with any questions. i think i saw something in the coming soon features of citrix a fix for this
n
We also use Okta here, so it may not be as straightforward.
d
we use Duo
oh sorry, didnt realize Okta has its own section in Citrix Identity.
behavior you list sounds EXACTLY the same as mine though. I'm assuming you have local DCs?
n
Yep
d
yea so i think thats why you get the PRT when you lock the PC. because when you unlock, the PC goes to local dc to grab what it needs for the PRT
it's pretty crazy that this is still an issue. I began my struggle with the problem last june and only got around it, by avoiding hybrid entirely, in like feb.
n
So if we disable hybrid join it works? lol
I can test that by disabling workplace join via GPO, actually.
d
trying to find the gpo setting i turned on for it to finally stop azure joining.
n
Register domain joined computers as devices
d
yea sounds like that one
Copy code
The hybrid Azure AD joining process is managed by Citrix. You need to disable autoworkpl aceJoin controlled by Windows in the master VMS as follows: 

1. Run gpedit. msc 

2. Navigate to Computer Configuration > Administrative Templates > Windows Components > Device Registration. 

3. Set Register domain joined computers as devices to Disabled.
n
I'll see if this does anything, but I know that MS will complain that "we should be hybrid-joining the devices to rule out issues"
d
yea but at least you can see if it'll do what you want it to
also as im sure you are aware, if you are using the latest fslgoix you might need to change the policy for identity roam
n
Yep. I initially disabled this at my last place by request of somebody else, but we eventually enabled it again. Never saw an issue with anything, but you never know.
d
im still on the older one bc truthly worried about auth issues after that nightmare
n
Nah, new place is a CPM shop.
d
ah ok
n
We were FSL at the last place, and honestly, I'd have switched to Citrix containers by now if I were still there.
d
I do hear good things. maybe that'll be a project for future
keep me posted with your results
n
Will do. Just gotta wait for replication to complete to test this.
m
Is Imprivata involved?
n
No Imprivata.
Disabling device registration via GPO doesn't appear to be working for me... and as I type that out, I recall that we added dsregcmd /join to our boot script in the platform layer. Nevermind, was thinking of the dsregcmd /leave that we added to our sealing script.
d
and when you do the dsregcmd command what does the vda say
n
AzureAdJoined: YES, DeviceAuthStatus: SUCCESS
two of the important ones
b
sealing with BISF 1912.6? Had a similar issue where dsregcmd /leave of my masterimage did not work.
d
@Nick Panaccio so mine is azuread joined: NO
azuread join: no enterprisejoin: no domainJoined: yes
i think i have the task schedule stuff disabled as well
@Balint Oberrauch needs azure CBA
j
Puzzling but if it works with rdp, that's Citrix. Maybe some GPOs break this. I would try with minimum GPO.
n
We have a ton of policies applied to the VDAs, but basically nothing in terms of Citrix. I'll give that a shot, thugh.
d
@Nick Panaccio was looking through my policies and could have swore i removed this one but its still there so maybe thats what making office work. User regkey removal - run it at logoff # Delete the Identity key from the registry Remove-Item -Path "HKCU:\Software\Microsoft\Office\16.0\Common\Identity" -Recurse -Force
now im scared to remove it from my policies..if it aint broke dont fix it...
n
MS recommends removing that, though I've never done it in the past. I'm still fighting with this issue, and am not sure if it's FAS, AAD, or something else. More testing needs to be done to pinpoint things.
First thing I want to test is a modified Automatic-Device-Join scheduled task (adding a startup trigger), but it is taking an act of god to get that created, since that is not my role at this place.
b
@Nick Panaccio you can achieve this also via BIS-F. This scheduled task is executing nothing else than dsregcmd /join at the first user login. I'm sure you know that, but BISF can be used to leave AAD on the masterimage and join AAD on the non-persistent VM's. Disable Workplace Join is also not needed when using AAD Hybrid Join. Only importance is to leave AAD when sealing (if your master image is AAD joined) otherwise you have duplicate objectGuids. SSO when using FAS with PRT Key via Citrix currently is only possible using the guide I've posted above. Hope this helps 🙂
and be aware that in BISF 1912.6 there's a bug regarding AAD. If you're using that version, update your ADMX and ADML Templates
n
The problem is that my team doesn't handle the image, and I don't think the team that does is interested in using BIS-F at this time. We have too much going on to even consider it.
@Rob Zylowski Can you think of anything App Layering related that would prevent us from modifying a scheduled task? No policy is doing this. When we edit the Platform layer, the packaging VM retains the new trigger in the task after multiple reboots. The compiled image, though? Missing, back to default.
r
Just a silly question are you sure you incremented the platform layer version in the image template. If you post what you are setting ill test it in my lab
n
New platform layer version, open scheduled tasks, open Automatic-Device-Join properties, select the Triggers tab, click on New and add a new trigger for At startup:
Rebooting the packaging VM repeatedly, the new trigger is still there. Compile the image with this platform layer version, and it's gone, reverting back to the screenshot above.
Wait, are these built-in scheduled tasks user-specific? That would make no sense, given that I have seen posts from people stating that they added triggers.
r
I know scheduled tasks end up in the registry will ahve to find where
n
Looks like here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache
r
So should be ok
let me test
n
I cracked open the image in private mode, added the trigger, sealed it back and and the trigger is still there.
r
What OS Nick?
n
W10 22H2
r
thanks
n
on 1912 CU6, with AL 2211
r
yea i wont be testing that exacly but wanted the os to be the same which it is
I have done sched tasks in layers and the os alyer but never in the platform alyer but i woudl expect it to work
n
Yeah, so would I. Which makes me think this is a procedural thing. I may sit with them and see exactly what they're doing to make sure nothing odd is going on.
r
Interesting. I added the trigger you weaned to the existing Automatic-Device Join and i also added a new scheduled task in the library. FOr the device join one that change is not in my image but the new task is. SO im not sure if ms didnt like a change to that or its a restriction we have. Ill ask the engineers about it and let you know if they know naything but you could replicate thta task in the library
h
1. @Nick Panaccio - As some one said, it is becoz of FAS, Im facing similar kind of issue, where PRT worked fine after disabling FAS Policy We had also tagged a case with Citrix and thy have shared this as workaround - : https://learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-certificate-based-authentication#step-2-enable-cba-on-the-tenant.
r
@Nick Panaccio let me work on that monday i am working w engineering on it
👍 1
n
@HD The workaround is to disable FAS and follow the steps in that link, or keep FAS enabled and follow the steps in that link? Don't think disabling FAS will fly here.
h
@Nick Panaccio I think we can keep the FAS enabled., To be honest, i yet to implement it
h
Has anyone discovered a good solution here yet?
n
For us, it was having the Identity team enable Okta Silent Activation. O365 activates at every launch for us now, but we no longer have token expiration issues, etc. Still a dumb solution, IMO, but at least it now works for us.
d
I disabled hybid join on the os
✅ 1