OK, the problem with this seems to be timing. Running a "cmdkey" command at logon allows the user access to the Azure share, but by then my service has already tried and failed to connect. So unless I can delay that action, I'm kinda snookered here. Either that or find some way to run the cmdkey command ridiculously early in the logon process, but even using tooling like AppSense this seems to be impossible.
Adding the credentials to the system default profile also seems to be a non-starter - the username for the share seems to persist, but the password is still prompted for. I'm thinking that stored password credentials are somehow hashed for or tied to the originating user, which to be honest I'd expect, otherwise credential theft would be incredibly easy. Think I'm going to write this one off as unachievable in the present state - thanks all for suggestions. From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] On Behalf Of James Rankin Sent: 17 March 2017 14:04 To: ntsysadm@lists.myitforum.com Subject: RE: [NTSysADM] RE: Persisting access to an Azure shared folder This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing> Feedback<http://aka.ms/SafetyTipsFeedback> I did try Group Policy with the delay set to 0, but it didn't manage to get in soon enough. However I didn't configure any of the other settings, let me give that a try. From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Stephen Gestwicki Sent: 17 March 2017 13:49 To: ntsysadm@lists.myitforum.com<mailto:ntsysadm@lists.myitforum.com> Subject: RE: [NTSysADM] RE: Persisting access to an Azure shared folder * You can use Group Policy to change the logon script delay but that only applies to Server 2012 R2+ and Windows 8.1+. o Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure Logon Script Delay = Enabled and set to 0 minutes * You can also try having the computer always wait for the network. o Computer Configuration > Policies > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon = Enabled * Another thing you can try is forcing each script to finish before allowing Group Policy to move on. o Computer Configuration > Policies > Administrative Templates > System > Scripts > Run startup scripts asynchronously = Disabled Those settings may give you a shot at having Group Policy run the script first but they will also slow down your logins. * I also like applying these settings to a test OU so I can see what is going on during my tests: o Computer Configuration > Policies > Administrative Templates > System > Display highly detailed status messages = Enabled o Computer Configuration > Policies > Administrative Templates > System > Scripts > Display instructions in shutdown scripts as they run = Enabled ? Warning: users can close out your script before it finishes. o Computer Configuration > Policies > Administrative Templates > System > Scripts > Display instructions in startup scripts as they run = Enabled ? Warning: users can close out your script before it finishes. I hope that helps. - Stephen From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Melvin Backus Sent: Friday, March 17, 2017 6:37 AM To: ntsysadm@lists.myitforum.com<mailto:ntsysadm@lists.myitforum.com> Subject: RE: [NTSysADM] RE: Persisting access to an Azure shared folder Given Windows post-XP tendency to delay logon scripts, etc., I would fully expect that the scheduled task route would run earlier than a logon script. Whether would run soon enough remains to be tested, but in my experience they seem to run first before anything else I've found. -- There are 10 kinds of people in the world... those who understand binary and those who don't. From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of James Rankin Sent: Friday, March 17, 2017 12:18 AM To: ntsysadm@lists.myitforum.com<mailto:ntsysadm@lists.myitforum.com> Subject: Re: [NTSysADM] RE: Persisting access to an Azure shared folder It needs to run in the user context, so it would have to be at logon. I wonder if a task would run earlier? Could be worth a bash... Sent from my slightly schizophrenic, but rather cool, BlackBerry Android From: kurt.b...@gmail.com<mailto:kurt.b...@gmail.com> Sent: 17 March 2017 12:40 a.m. To: ntsysadm@lists.myitforum.com<mailto:ntsysadm@lists.myitforum.com> Reply to: ntsysadm@lists.myitforum.com<mailto:ntsysadm@lists.myitforum.com> Subject: Re: [NTSysADM] RE: Persisting access to an Azure shared folder Scheduled task at startup? Kurt On Thu, Mar 16, 2017 at 3:48 PM, James Rankin <ja...@htguk.com<mailto:ja...@htguk.com>> wrote: That's what I've been trying, but the net use command, when run at logon, doesn't execute early enough to get in "ahead" of the write to the share, sadly. In order to get it done for new users was the rationale around seeing if I could get it in the default profile, but unfortunately sysprep seems to remove saved passwords (although not usernames, oddly) So net use works, but somehow I need to get it to execute earlier than seems possible at the moment, hence trying to think of a different approach... Sent from my slightly schizophrenic, but rather cool, BlackBerry Android From: mich...@smithcons.com<mailto:mich...@smithcons.com> Sent: 16 March 2017 10:44 p.m. To: ntsysadm@lists.myitforum.com<mailto:ntsysadm@lists.myitforum.com> Reply to: ntsysadm@lists.myitforum.com<mailto:ntsysadm@lists.myitforum.com> Subject: [NTSysADM] RE: Persisting access to an Azure shared folder I'm not saying that there isn't a better solution... and I'd love to know one. But I've had people executing the "net use /persist" from a batch file (or sending around an intern to do it). From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com>] On Behalf Of James Rankin Sent: Thursday, March 16, 2017 3:39 PM To: ntsysadm@lists.myitforum.com<mailto:ntsysadm@lists.myitforum.com> Subject: [NTSysADM] Persisting access to an Azure shared folder I have a shared folder set up in Azure which can be mapped via SMB. You can access this by a "net use" command which specifies a username and password. However I want all of my users to be able to write out to this share, but I need the access to be available from quite early in the logon process (I'm writing some user-specific configuration files out to the share during user logon). How can I give *all* users access to this area? I thought I could use Audit Mode to create a custom default user profile that already has supplied the username and password and saved them into %LOCALAPPDATA%\Microsoft\Credentials, but set up in this way it still prompts for a username and password and henceforth the write to the Azure share fails with an Access Denied error. Any ideas? Or should I really be standing up some Windows file servers in Azure along with some proper AD authentication? All suggestions gratefully welcomed... Cheers, James Rankin CTA ACA EUC Solutions Architect Howell Technology Group Office: 0191 4813446 Mobile: 07809 668579 Email: ja...@htguk.com<mailto:ja...@htguk.com> www.htguk.com<http://www.htguk.com/> | Twitter<https://twitter.com/htguk> | Linkedin<https://www.linkedin.com/in/markhtg> | Facebook<https://www.facebook.com/HTGUK> COMPANY INFORMATION Howell Technology Group Ltd is a limited company registered in England with registered number 5520670 and VAT registered number GB 862 666 004. Our registered office is at 2.30 One Trinity Green, Eldon Street, South Shields, Tyne & Wear, NE33 1SA CONFIDENTIALITY NOTICE This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment. PRIVACY POLICY For information about how we process data and monitor communications please see our Privacy Policy. To log a ticket please follow the link. https://htguk.on.spiceworks.com/portal
