none
DirectAccess Group Policy / Logon Script Behaviour on Authenticated Wireless

    Pergunta

  • I just finished deploying a production DirectAccess environment with Multisite and compatibility for Windows 7 and Windows 8. DA has been awesome and been running rock solid. But we've run into a weird problem and I can't seem to find a reasonable solution for it:

    We have an Authenticated Wireless network at the office that uses Windows Session credentials, so you don't actually connect and get issued an IP Address until after you log in to Windows. What we've found is that DirectAccess will obviously connect as soon as there is an active internet connection but the typical Group Policy / Home Folder / Logon Script experience fails to run if you prevent DA from connecting pre-logon.

    We've confirmed that it's still functioning correctly by testing it outside the office, for example, if I take my corporate laptop home, it will connect to my wireless network at home pre-logon and once my logon finishes I get my Home Folder and logon scripts executed.

    So, our question is basically this: How do you get a DA client to execute the "AD logon experience" if DA connects AFTER the user finishes a logon? (Our execs have already complained that this behavior also happens on airport or hotel wireless where you don't get internet access until you open the browser and sign your life away)

    segunda-feira, 22 de julho de 2013 13:42

Respostas

  • Its not the most ideal solution, but I found a method to trigger a post-script execution:

    Adding a scheduled task that executes on an event:

    Log:    Microsoft-Windows-Iphlpsvc/Operational

    Source:    Iphlpsvc

    Event ID:    4500

    Added with the following:

    - Run Logon script from domain UNC (i.e. \\domainname.local\whatever\script.bat)

    - Delay Task for 1 minute (to give the Infrastructure and User Session Tunnels a chance to finish establishing)

    - Run only when user is logged on

    - UNCHECK "start the task only if the computer is on AC power"

    It will trigger twice, as the IP Helper Service logs two of these events after establishing a DA connection, but depending on how long it takes your script to execute (i.e you have a gpupdate /force in there) it may only run once if you leave the default "do not start a new instance" if the task is already running.

    • Marcado como Resposta dustin.adam segunda-feira, 22 de julho de 2013 21:12
    segunda-feira, 22 de julho de 2013 21:12

Todas as Respostas

  • As you have found, one of the great things about DirectAccess is that it connects as soon as internet is available, even from the login screen. This enables those Active Directory driven things to run real-time as the user is logging in, just like when plugged into the corporate network. When you log into Windows and there is no internet access therefore no DirectAccess, there is no connection to Active Directory and those things cannot run. There isn't anything you can do from a DirectAccess perspective to change this. No internet, No DA, No AD processing.

    Group Policy runs and refreshes typically on a scheduled interval, so in these cases eventually GPO settings should get pulled down, but you are correct that login scripts aren't going to wait around and run once connection does get established. The place you would need to change behavior is in the scripts and settings themselves, but I don't know of anything specific that I could tell you to do that would cause them to delay until connection is available. Maybe a customized script that waits until it has SMB access to a file share or something like that. That way your script is doing the work of making sure that intranet connectivity is established before trying to run.

    segunda-feira, 22 de julho de 2013 18:18
  • Yeah, I understand all that... I guess my confusion stems from the fact that this isn't a new problem, it's been around since the early days of VPN access when you always missed authenticating against your DC's. Most VPN connection apps out there support running post connection scripts to help bridge that gap. Cisco's ASA, heck, even with RRAS you can set it up to run scripts after connection. I guess it seems a little short-sighted on Microsoft's part to assume that DA Client worldwide would ALWAYS have internet access pre-logon, and offer no other method of running a script post-logon. It's not really the end of the world, it just limits some of our capability.
    segunda-feira, 22 de julho de 2013 19:47
  • Its not the most ideal solution, but I found a method to trigger a post-script execution:

    Adding a scheduled task that executes on an event:

    Log:    Microsoft-Windows-Iphlpsvc/Operational

    Source:    Iphlpsvc

    Event ID:    4500

    Added with the following:

    - Run Logon script from domain UNC (i.e. \\domainname.local\whatever\script.bat)

    - Delay Task for 1 minute (to give the Infrastructure and User Session Tunnels a chance to finish establishing)

    - Run only when user is logged on

    - UNCHECK "start the task only if the computer is on AC power"

    It will trigger twice, as the IP Helper Service logs two of these events after establishing a DA connection, but depending on how long it takes your script to execute (i.e you have a gpupdate /force in there) it may only run once if you leave the default "do not start a new instance" if the task is already running.

    • Marcado como Resposta dustin.adam segunda-feira, 22 de julho de 2013 21:12
    segunda-feira, 22 de julho de 2013 21:12