Hello,
I use DO quite a bit at work in a corporate environment. I frequently map to shares using the usual "\\server\share" syntax.
I've noticed that for DO only, I'm required to enter my credentials twice. At first I thought it was me mistyping, but upon testing I see that it simply happens that way each time.
Best,
--J
Are you mapping a drive letter, or going direct to the UNC path? (Or both?)
What happens if you do the same in File Explorer (after disconnecting any connections, of course.)
Hello,
Going direct to the UNC path. For example in the Favorites I have a few folders for \\servername\c$
I rarely if ever map drive letters.
I tested using Windows Explorer, after reboots, etc. I only have to enter it once when using stock Explorer.
That's strange. I do that all the time in Opus and only have to enter the password once (unless I get it wrong, of course).
Only exception I've seen is after the Windows 10 2004 update, where the OS itself randomly forgets network drive passwords (among other things, e.g. Chrome constantly logging out of your account). I rolled back to 1909 to fix that.
Due to security, we don't remember passwords like that - I have to enter passwords all day long.
Of note. My logged in account is foo.bar. The share I'm attempting to access I enter credentials as baz.bash. But to reiterate, not getting that issue using Windows Explorer.
Of note, on my home machine I have a NAS. I'll try this later today but I remember also having the same problem of having to re-enter credentials. That machine is of course not on a corporate network.
Best,
--J
Windows itself will usually remember IPC/SMB credentials until the client logs out, otherwise you'd be asked for them every time the server/shared was accessed.
You can see them via net use from a command prompt.
I wonder if there is something on the machine which clears connections so they aren't remembered for as long?
Another thing is to make sure you haven't launched Opus elevated, as that can make network share access more complicated.
Sorry, yes... once entered the credentials are good for the duration of the login.
Running net use right now, hours after the credentials were first entered, shows them as still valid. I don't have any issues once authenticated, it's just the initial handshake.
I don't run DO elevated.
I should add, I'm running the 12.21.5 beta.
Is there any logging I can turn on or the like which might assist tracking it down?
Best,
--j
It might be worth checking what net use shows before any connection is made, and then see what it shows after the first time you type the password, then after the second time.
Another thing to check: If you cancel the second prompt, can you still access the folder after that? It's possible something is triggering the two prompts in parallel, such that the 2nd one isn't necessary but has already been triggered. If that's happening it would give us something to investigate.
I took the direction... here is what happened:
\\fubar\c$
\\fubar
Once credentials are entered in either DO or windows explorer, I'm not asked again in either program, and net use shows me authenticated for the life of my login.
In answer to your second question about canceling the second prompt; I cannot access the folder afterwards. If I try to go there again, it will do the double prompt again. Basically it's a double prompt and then I'm in.
What software is at the other end (server)? Win Server, Samba, something else?
Windows mixture; 2012R2 and 2016 and 2019. No Samba.
Best,
--J
FYI I also tried entering in bad credentials the first time, to see if it was just ignoring my first entry, and that's not the case. It made me enter in credentials a total of three times (1 bad, 2 good) when I did that.
I'm not sure what's happening there. Definitely different to what I see here, on several machines.
I haven't had a chance yet, but I'd like to make a small test program which calls the API for authenticating against the share and reports the result, for you to try. That will tell us if the API is working as expected, in a simple test app.
Leo,
So this weekend on my home computer, attempting to access my NAS, I had the same trouble. My home computer is not on a Domain, just a normal Windows installation. I rebooted and attempted to access the directory on the NAS a few times, different ways. It's a QNAP NAS so it's Linux/SMB.
Same problem... windows explorer only asks me once, DO twice.
I apologize if my previous posts were misleading pointing to a domain, C$ issue.
Best,
J
So you're seeing this with normal shares, not just the C$ admin shares? Those (normal ones) are the kind I use all the time without issue.
Which version(s) of Windows do you have on the two affected machines? (e.g. Win10 1909, 2004, etc.)
Is there anything in common with the two machines, such as antivirus or firewall software?
What's the exact method you're using to navigate to the share? (I usually go to mine via an alias typed in, e.g. typing /d into my file display takes me to \\myserver\myshare$, prompting me for credentials if the client side has been rebooted since the last time.)
I think this must have been caused by yet another bug in Windows updates, because I can reproduce this on my 2004 machine now. (I don't reboot it often, which might be why I hadn't noticed it before now.)
One thing I noticed, at least on my machine, is that the second prompt already has the password filled in, so I just have to push return an extra time. I'm not sure what's going on there, but now that we can reproduce it we can look into it in more detail. Maybe we can find a workaround for it, or maybe Microsoft will fix it (and probably break something else) in a new update.
Edit: This still doesn't happen on my Win10 1909 machine, only the Win10 2004 one, which supports the theory that it's a Windows bug. (2004 is the named version number, not a release year.) So far, it looks like WNetAddConnection3 no longer works correctly the first time it is called.
Leo,
That's a relief! I purchased DO right around the time I converted to Windows 10 2004 so I probably didn't see the change.
One further observation: For both 1909 and 2004, File Explorer doesn't prompt for credentials at all when doing the same thing here. It just shows an error message.
We're still looking into whether we can make it work in Opus.
After investigation, we cannot see a way to fix this. It is a bug introduced in Windows 10 2004 where WNetAddConnection3 prompts you for the password, then prompts you a second time.
The second prompt has the password already filled in (at least for us), so you can just push return at that point, if you're confident you typed it correctly.
Both prompts result from a single call to WNetAddConnection3, and none of our code executes between the two prompts, so we can't do anything to stop them.
Hopefully Microsoft will fix this. They also seem to have broken the same functionality entirely in File Explorer in 2004, at least on both my 2004 machine and Jon's.
(One last thing we're considering is showing our own custom password prompt, but we aren't sure if that will fix the problem or if it's a good idea. It may also block other things that the normal API can do, which wouldn't be ideal.)
Thank you for the explanation. Now that I know what the problem is and the workaround, I won't worry further.
Best,
--J