Hey all, I've already submitted a bug report on this to Apple (4704930) *and* Microsoft, but was hoping for some insight as to what might be an option for when Vista is released... On my OSX server, I put application installers (Mac and Windows) up so my users can follow e-mailed instructions to install them if they need them. With Vista (all seeds post b1), the following will occur if User Access Control (UAC) is on the Vista client (which it is by default) and the Vista user attempts to install a Windows app located on my OSX Server:1) Vista User connects to my file server by typing in "\\<hostname>" and logging into the server.2) User navigates to Windows app installer directory3) User double-clicks on Setup.exe (doesn't really matter what Windows app it is...)4) User gets an "Open File -- Security Warning" box (click "run") (XP users see this now -- nothing new here...)5) User Account Control box comes up -- click "continue"6) "Cannot Access network resource box" comes up with a need to reenter the server login/password again.Now, with B1 of Vista -- after reauthenticating to the server -- the Windows app installer would run.What is happening with all the builds of Vista since Beta 1 (which means it's in RC1 and the post-RC1 build, so it's probably "expected behavior" now) is that Step 6 above comes up again. And again. And again...The Windows application installer will never fire up because that dialog box will never stop coming up.The only workaround I've been able to come up with is to turn UAC *off*. For which Vista nags you about it.Or put the Windows app installers on an honest-to-gosh Windows machine. Which I don't want to do.I'm taking this to mean it may be a SAMBA issue (as the problem seems not to be limited to OSX *Server* as it happens if I move the installer to OSX Client and turn Windows Sharing on it as well...)But OSX Server seems to have a bit more GUI options as to what might be toggled for Windows authentication/Samba (though toggling all the options didn't make any difference.)It's certainly 100% reproducable, but because MS hasn't changed the behavior back to beta1 behavior no matter how many times I submit the bug, I'm fully expecting this to be in Vista GM.Vista is (for better or worse) going to hit here soon after release so it's becoming more of a pressing issue than I'd hoped.Anybody run across this yet and have any thoughts on this matter?Any MS network Engineers care to chime in on this one?- Steve

This definately sounds like a Samba->Vista issue. What do you have set on the Vista machine for "Microsoft Network Client: Digitally sign communications (always)" in your group policy? Is it set to enabled? If so, then that could be the issue.

I'm using the default settings for the client (5728 now) which would be:Digitally sign communications (always): disabledDigitally sign communications (if server agrees): enabledSend unencrypted password to third-party SMB servers: disabled.I'd have to go way back to install b1 again to see if any of these were different then.Suggestions on which to toggle first if that's the case?

Well, those are the right settings...I'll try to talk with my Mini tomorrow night and see if I can repro. I so, I will post it as a bug.

Any luck reproducing this? I wonder if this is one of the mythical "1400 open bugs" that Paul Thurrott seems to refer to:http://www.windowsitpro.com/windowspaulthurrott/Article/ArticleID/93715/windowspaulthurrott_93715.html- Steve

Holy ***.This bug seems to be fixed in RC2.I honestly don't believe it...

***...Now that I have the RTM build -- this bug is *back* (!)Anybody else confirm this?AAARRGH!

The problem seems to be with NTLMv2 authentication.If this is set in the security policy in RC2 (and later) builds -- everything works fine.In RTM -- I have to back it off to NTLM authentication.GAH! Why did they break this in RTM!- Steve

I know. Depressing isn't it? I get the you don't have permissions to access this server. Please contact the admin of the server. Funny thing is that I am the admin! lolWould be nice if they had this working.I'm running into an even odder issue now with communicating/pinging a linux router to a Wamnet OC3 box. I've added the persistent route and I can't ping the address. Says Destination Host Unreachable yet no lost packets! XP works great of course!