Re: Access denied on Homeshare with FQDN, fine with Shortname
- From: Hmoll <Hmoll@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 31 Aug 2007 06:10:01 -0700
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@xxxxxxxxx> wrote in message.
news:1188486751.680627.57980@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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...@xxxxxxxxxxxxxxxxxxxxxxxxx> 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.
- References:
- Re: Access denied on Homeshare with FQDN, fine with Shortname
- From: jwgoerlich
- Re: Access denied on Homeshare with FQDN, fine with Shortname
- From: Roger Abell [MVP]
- Re: Access denied on Homeshare with FQDN, fine with Shortname
- From: Hmoll
- Re: Access denied on Homeshare with FQDN, fine with Shortname
- From: jwgoerlich
- Re: Access denied on Homeshare with FQDN, fine with Shortname
- From: Roger Abell [MVP]
- Re: Access denied on Homeshare with FQDN, fine with Shortname
- Prev by Date: Re: Access denied on Homeshare with FQDN, fine with Shortname
- Next by Date: Re: history
- Previous by thread: Re: Access denied on Homeshare with FQDN, fine with Shortname
- Next by thread: Yellow Shield system tray icon
- Index(es):
Relevant Pages
|
