Access denied on Homeshare with FQDN, fine with Shortname

[Hmoll]

I'm getting a strange error where I am getting an access denied on my
homeshare. But only when using FQDN to define my server.

If I change from \\servername.domain.local\homeshare$ to simply
\\servername\homeshare$, everything works.

This is only happening on some Vista machines that are in the same OU as the
other Vista machines. This problem does not manifest itself on XP.

Any ideas why Vista doesn't work with FQDN defined homeshares.... or at
least on SOME of my machines?

NOTE: I can also *fix* this problem by leaving it an FQDN, but changing from
user-specific to Everyone or Authenticated Users on the Share ACL. Well,
that's not really fixing it....

 

[jwgoerlich@gmail.com]

Try adding file://*.domain.local, http://*.domain.local, and
https://*.domain.local to the Local Intranet security zone. This is in
Internet Explorer under Tools > Internet Options, Security tab. Click
to select Local Intranet and add the URLs under Sites.

Regards,

J Wolfgang Goerlich


On Aug 29, 1:06 pm, Hmoll <Hm...@discussions.microsoft.com> wrote:
> I'm getting a strange error where I am getting an access denied on my
> homeshare. But only when using FQDN to define my server.
>
> If I change from \\servername.domain.local\homeshare$ to simply
> \\servername\homeshare$, everything works.
>
> This is only happening on some Vista machines that are in the same OU as the
> other Vista machines. This problem does not manifest itself on XP.
>
> Any ideas why Vista doesn't work with FQDN defined homeshares.... or at
> least on SOME of my machines?
>
> NOTE: I can also *fix* this problem by leaving it an FQDN, but changing from
> user-specific to Everyone or Authenticated Users on the Share ACL. Well,
> that's not really fixing it....

 

[Hmoll]

Leider nicht....

The changes did not have an effect.

"jwgoerlich@gmail.com" wrote:

> Try adding file://*.domain.local, http://*.domain.local, and
> https://*.domain.local to the Local Intranet security zone. This is in
> Internet Explorer under Tools > Internet Options, Security tab. Click
> to select Local Intranet and add the URLs under Sites.
>
> Regards,
>
> J Wolfgang Goerlich
>
>
> On Aug 29, 1:06 pm, Hmoll <Hm...@discussions.microsoft.com> wrote:
> > I'm getting a strange error where I am getting an access denied on my
> > homeshare. But only when using FQDN to define my server.
> >
> > If I change from \\servername.domain.local\homeshare$ to simply
> > \\servername\homeshare$, everything works.
> >
> > This is only happening on some Vista machines that are in the same OU as the
> > other Vista machines. This problem does not manifest itself on XP.
> >
> > Any ideas why Vista doesn't work with FQDN defined homeshares.... or at
> > least on SOME of my machines?
> >
> > NOTE: I can also *fix* this problem by leaving it an FQDN, but changing from
> > user-specific to Everyone or Authenticated Users on the Share ACL. Well,
> > that's not really fixing it....
>
>
>

 

[Roger Abell [MVP]]

"Hmoll" <Hmoll@discussions.microsoft.com> wrote in message
news:22A868A1-A8C3-46A5-92B7-FD55A8BA036F@microsoft.com...
> Leider nicht....
>
> The changes did not have an effect.
>

Enable logon failure auditing on machine "servername" to see
why the authentication did not happen or failed.

Buy strange message I assume you only mean that you get the
widely recognized You do not have permissions to access . . .
popup message ?

> "jwgoerlich@gmail.com" wrote:
>
>> Try adding file://*.domain.local, http://*.domain.local, and
>> https://*.domain.local to the Local Intranet security zone. This is in
>> Internet Explorer under Tools > Internet Options, Security tab. Click
>> to select Local Intranet and add the URLs under Sites.
>>
>> Regards,
>>
>> J Wolfgang Goerlich
>>
>>
>> On Aug 29, 1:06 pm, Hmoll <Hm...@discussions.microsoft.com> wrote:
>> > I'm getting a strange error where I am getting an access denied on my
>> > homeshare. But only when using FQDN to define my server.
>> >
>> > If I change from \\servername.domain.local\homeshare$ to simply
>> > \\servername\homeshare$, everything works.
>> >
>> > This is only happening on some Vista machines that are in the same OU
>> > as the
>> > other Vista machines. This problem does not manifest itself on XP.
>> >
>> > Any ideas why Vista doesn't work with FQDN defined homeshares.... or at
>> > least on SOME of my machines?
>> >
>> > NOTE: I can also *fix* this problem by leaving it an FQDN, but changing
>> > from
>> > user-specific to Everyone or Authenticated Users on the Share ACL.
>> > Well,
>> > that's not really fixing it....
>>
>>
>>

 

[Hmoll]

* 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.


"Roger Abell [MVP]" wrote:

> "Hmoll" <Hmoll@discussions.microsoft.com> wrote in message
> news:22A868A1-A8C3-46A5-92B7-FD55A8BA036F@microsoft.com...
> > Leider nicht....
> >
> > The changes did not have an effect.
> >
>
> Enable logon failure auditing on machine "servername" to see
> why the authentication did not happen or failed.
>
> Buy strange message I assume you only mean that you get the
> widely recognized You do not have permissions to access . . .
> popup message ?
>
> > "jwgoerlich@gmail.com" wrote:
> >
> >> Try adding file://*.domain.local, http://*.domain.local, and
> >> https://*.domain.local to the Local Intranet security zone. This is in
> >> Internet Explorer under Tools > Internet Options, Security tab. Click
> >> to select Local Intranet and add the URLs under Sites.
> >>
> >> Regards,
> >>
> >> J Wolfgang Goerlich
> >>
> >>
> >> On Aug 29, 1:06 pm, Hmoll <Hm...@discussions.microsoft.com> wrote:
> >> > I'm getting a strange error where I am getting an access denied on my
> >> > homeshare. But only when using FQDN to define my server.
> >> >
> >> > If I change from \\servername.domain.local\homeshare$ to simply
> >> > \\servername\homeshare$, everything works.
> >> >
> >> > This is only happening on some Vista machines that are in the same OU
> >> > as the
> >> > other Vista machines. This problem does not manifest itself on XP.
> >> >
> >> > Any ideas why Vista doesn't work with FQDN defined homeshares.... or at
> >> > least on SOME of my machines?
> >> >
> >> > NOTE: I can also *fix* this problem by leaving it an FQDN, but changing
> >> > from
> >> > user-specific to Everyone or Authenticated Users on the Share ACL.
> >> > Well,
> >> > that's not really fixing it....
> >>
> >>
> >>
>
>
>

 

[jwgoerlich@gmail.com]

My thought is Windows Vista recognizes the FQDN as an Internet site
rather than a local computer. If this were the case, then Vista would
not pass on the user credentials. The share would be inaccessible
unless Everyone was granted permission. 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.

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.

Here is something to try. Open Windows Explorer from a Vista computer.
Browse to the network share. In the status bar in the lower right
corner, what does it say? Is it Local intranet or something else?
Please test this four ways: from a working Vista computer to the host
name, from working to the FQDN, from a non-working Vista to the host
name, and again from a non-working machine to the FQDN. Perhaps this
will point out a difference, or rule out this line of thinking
altogether.

Regards,

J Wolfgang Goerlich


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.

 

[Roger Abell [MVP]]

<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.
>

 

[Hmoll]

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.
> >
>
>
>

 

[Roger Abell [MVP]]

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.
>> >
>>
>>
>>

 

[jwgoerlich@gmail.com]

The status bar in the bottom of Windows Explorer may be turned off.
Try Windows Explorer > View > Status Bar. Not having a Vista machine
in the lab, I cannot tell if this works the same. Your working machine
displays what I had anticipated.

I worked thru a similar issue in the past with non-Windows servers
with FQDN shares, and the fact that the share was in the Internet zone
did cause an issue. Yet what I saw before and you are seeing now
appears to have two different causes.

What does the user see in Windows Vista? At what point does the error
occur? After login, upon accessing data files, upon running
executables, or someplace else? Any details you can think of will be
helpful, but the exact error message, verbatim, is key.

J Wolfgang Goerlich

On Aug 31, 9:10 am, Hmoll <Hm...@discussions.microsoft.com> wrote:
>
> @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.)
>