I have to think about this, as there are many clues but I do not see
how they add up. If the success of Authenticated Users could just
be understood . . .
That means that the domain has authenticated the accessing user
(we are using only domain accounts here, right?), which fits with
the lack of any login failure messages.
But then the question is how does that fit with the failures.
If it hits me I will of course post back.
"Hmoll" <Hmoll@discussions.microsoft.com> wrote in message
news:3F201F01-92AC-470C-B450-ECFD7ABFE36C@microsoft.com...
> Thank you both so much for the help on this. At present, I'm out of the
> office and working from home (ie, on my local LAN, behind a firewall and
> cable modem.) I am VPN'ing in, at the Ctrl-Alt-Delete screen (ie, select
> switch user, dial VPN, etc.) So hopefully, I am getting the same kerb
> ticket
> that I would normally.
>
> That being said, I got the same behavior when I was in the office, on the
> Corporate LAN.
>
> @Wolfgang:
> I'm a little confused. When using Windows Explorer, I don't get a status
> bar at the lower right hand corner (like I do, when using Internet
> Explorer.)
> When using Internet Explorer:
> * On the non-working machine, both show Intranet (I manually added to th
> Intranet sites, as suggested in previous posts)
> * On working machine: Hostname, Intranet/FQDN, Internet (despite being
> on
> the local lan... very strange.)
>
> @Roger
> * We are a single domain (dns and AD) environment. Everything is
> *.company.local. There is no disjunct.
> * "....that is why cred aren't being passed" Ah, this is interesting.
> Perhaps this is why I never see a failure in the Security Event Viewer
> log.
> Are there any troubleshooting logs I can see on the client, except event
> viewer (which shows nothing... at least with default settings.)
> * I triple checked: Authenticated Users works with the FQDN and does not
> prompt for creds (I removed ALL ACL entries and only put in a
> "Authenticated
> Users" Full Control entry.
> * Time: examining the LOGONSERVER variable to determine DC, I checked to
> ensure the times were syncing correctly. They were.
>
> The only reason I'm using FQDN's is to ensure all my mobile only users
> will
> definitvely get name resolution. In the past, I have had problems when
> mapping using the shortname when the user starts on their home (dsl/cable
> modem) network and then VPN's into the corporate net. The problems were
> name
> resolution related.
>
>
>
> "Roger Abell [MVP]" wrote:
>
>> <jwgoerlich@gmail.com> wrote in message
>> news:1188486751.680627.57980@r34g2000hsd.googlegroups.com...
>> > My thought is Windows Vista recognizes the FQDN as an Internet site
>> > rather than a local computer.
>>
>> Yes, assuming the DNS domain of the FQDN target server is
>> not the same as the DNS domain of the troubled Vista client.
>> One of my lines exploration also, though and an assumption
>> is needed this Vista is DNS disjunct from its DNS domain of
>> server relative to their FQDNs.
>>
>> > If this were the case, then Vista would
>> > not pass on the user credentials.
>>
>> Yep
>>
>> > The share would be inaccessible
>> > unless Everyone was granted permission.
>>
>> Umm. Why did the server not prompt for credentials ?
>> I took the posts to mean challenge for creds did happen
>> but that they result in an access denied message
>>
>>
>> > Use the host name rather than
>> > the FQDN, then Vista sees it as a computer on the Lan, passes the
>> > credentials and all is well.
>> >
>>
>> You are assuming that Windows authN mechanism works when
>> manually providing the same identity credentials at the prompt
>> for them fails. ?
>>
>> > Granted, this does not completely cover the facts. If the above was
>> > the case, one would assume that granting Everyone access would work
>> > and yet granting Authenticated Users would fail.
>> >
>>
>> Indeed. That difference is pivotal in this puzzle.
>>
>>
>> I am wanting to know what are the time differences pairwise between
>> the parties: the Vista, the server, and the domain controller(s) in use
>> by them. Again, if it is a Kerberos support issue (i.e. FQDNs are of
>> the same DNS domain), it is lacking in accounting for the reported
>> success ACL's with Authenticated Users. The first * could be time
>> drift between the different machines the second * would be expected
>> as shortname forces use of non-Kerberos authN the last * we have
>> agreed makes sense if report of Authenticated Users to resolve is
>> mistaken, else this * is most obscure.
>>
>> >
>> > On Aug 30, 8:18 am, Hmoll <Hm...@discussions.microsoft.com> wrote:
>> >> * Strange that on one machine it works, another it doesn't (despite
>> >> being in
>> >> the same OS, same OU, same user)
>> >> * Strange that if I use shortname rather than FQDN, it works, but the
>> >> more
>> >> reliable (for VPN users) FQDN fails
>> >> * Strange that if I change from user specific ACL on the share to
>> >> Everyone
>> >> or Authenticated users, it works.
>> >>
>> >> Ugggh. Security auditing gleaned nothing. I turned on Account logon,
>> >> logon
>> >> and object access auditing. There were no failures that I could see.
>> >>
>> >> Thanks for you help on this, I'm pulling my hair out.
>> >>
>> >> I installed this Vista Business while at home. I then connected to
>> >> the
>> >> corporate network the next day. That is the only difference in the
>> >> setup. I
>> >> wonder if there were any default security policies setup when I
>> >> slected
>> >> "Home", when I was at home.
>> >
>>
>>
>>