Non-domain computers can't access domain file shares properly

I apologize upfront for the cross posting, but I'm not fully certain
which group this post belongs in.

Anyway I have a unique situation here at my office. We run a Windows
Server 2003 R2 server which is the domain controller for an Active
Directory domain that we use. Currently we use the server itself as
well as a member server and a WinXP system (also AD member) for file
storage which houses among other things, patches, updates, 3rd party
software applications that we use when customers drop off their
computers for repair.

The purpose of our setup is to take customer computers, backup
personal data, reformat the system, reinstall the OS, install AV
software, patches, and finally restore the customers data. This setup
been working fine for several years, but back in December when our own
server crashed and involved a replacement and rebuilding a new active
directory, this stopped functioning. Of course after that I rebuilt
the domain, re-joined all of the above mentioned systems to the new
domain.

The issue that is happening is that any customer could bring any
desktop or laptop that we could either via ethernet or wireless, we
could access the shares by going to \\<server>\<share>. Of course the
next box/prompt would be to login/authenticate of which I would use
'administrator' and then 'mypassword' and instantly gain access to any
share on my network that I needed.

That worked fine if I was accessing file shares on the XP file share,
the Win2003 server file shares, etc. Previously it seemed when a non-
domain PC accessed an AD member share, that member PC would
authenticate against the Win2003 AD user database. However, things
with this have changed.

Now when I use any non-domain member PC or laptop and try to access a
hidden or non hidden share on another member XP/2003 system, I still
get the same prompt to login. But now when I use 'administrator' and
'mypassword' it rejects access until I use the login of 'my-domain
\administrator' and then 'mypassword'. Once I use those credentials
it lets me in just fine. However when logging into a share on the
domain controller itself, then I can login the old way.

When I try to login to an AD member file share, it appears that the AD
member is NOT using the domain controller to authenticate the
'administrator' / 'mypassword' credentials I typed in, instead trying
to authenticate against the non-domain PC I'm typing at. I suspect
that is happening because the result is that I get a message that the
following username and password are invalid and it indicates the
username is 'ACER-065703\administrator' is not a valid logon. Where
ACER-065703 is the PC name of this specific computer.

Before I go further I know I may get some flame responses of "Active
Directory isn't designed to work that way or let non-domain members
in". And yes I know that. But the way our office is running things
this is the best way for us to accomplish what we want to do. I've
also scoured the internet via google trying to find a solution to this
and have not been successful.

The ironic thing, is when I have personally installed Windows Server
2003 Active directory networks for clients, this has never been a
problem like it is above for our office. It was so frustrating that
one weekend I came in, setup a new Windows Server 2003 system, new
test active directory setup, but still when a non-domain member
computer tries to access a share on either a domain server or domain
member system, I'm still required to use 'my-domain\administrator' and
'mypassword'.

Can anyone be of help? I can't figure out if this is a DNS issue
(appears to be...????) or if something needs to be changed in DHCP so
that DHCP tells what domain control to authenticate against??

Help!!

Responded inline below...

"modem" <(E-Mail Removed)> wrote in message
news:5a3d7031-5ddc-486d-af63-(E-Mail Removed)...
>I apologize upfront for the cross posting, but I'm not fully certain
> which group this post belongs in.
>
> Anyway I have a unique situation here at my office. We run a Windows
> Server 2003 R2 server which is the domain controller for an Active
> Directory domain that we use. Currently we use the server itself as
> well as a member server and a WinXP system (also AD member) for file
> storage which houses among other things, patches, updates, 3rd party
> software applications that we use when customers drop off their
> computers for repair.
>
> The purpose of our setup is to take customer computers, backup
> personal data, reformat the system, reinstall the OS, install AV
> software, patches, and finally restore the customers data. This setup
> been working fine for several years, but back in December when our own
> server crashed and involved a replacement and rebuilding a new active
> directory, this stopped functioning. Of course after that I rebuilt
> the domain, re-joined all of the above mentioned systems to the new
> domain.
>
> The issue that is happening is that any customer could bring any
> desktop or laptop that we could either via ethernet or wireless, we
> could access the shares by going to \\<server>\<share>. Of course the
> next box/prompt would be to login/authenticate of which I would use
> 'administrator' and then 'mypassword' and instantly gain access to any
> share on my network that I needed.
>
> That worked fine if I was accessing file shares on the XP file share,
> the Win2003 server file shares, etc. Previously it seemed when a non-
> domain PC accessed an AD member share, that member PC would
> authenticate against the Win2003 AD user database. However, things
> with this have changed.
>
> Now when I use any non-domain member PC or laptop and try to access a
> hidden or non hidden share on another member XP/2003 system, I still
> get the same prompt to login. But now when I use 'administrator' and
> 'mypassword' it rejects access until I use the login of 'my-domain
> \administrator' and then 'mypassword'. Once I use those credentials
> it lets me in just fine. However when logging into a share on the
> domain controller itself, then I can login the old way.

That is because the local machine thinks that you are trying to use it's
local administrator account. So when you use domain\administrator method,
the local machine now knows that you mean to use the domain's administrator
account

>
> When I try to login to an AD member file share, it appears that the AD
> member is NOT using the domain controller to authenticate the
> 'administrator' / 'mypassword' credentials I typed in, instead trying
> to authenticate against the non-domain PC I'm typing at. I suspect
> that is happening because the result is that I get a message that the
> following username and password are invalid and it indicates the
> username is 'ACER-065703\administrator' is not a valid logon. Where
> ACER-065703 is the PC name of this specific computer.

That is expected behavior.
You can possibly get around it by making the passwords identical.

>
> Before I go further I know I may get some flame responses of "Active
> Directory isn't designed to work that way or let non-domain members
> in". And yes I know that. But the way our office is running things
> this is the best way for us to accomplish what we want to do. I've
> also scoured the internet via google trying to find a solution to this
> and have not been successful.
>
> The ironic thing, is when I have personally installed Windows Server
> 2003 Active directory networks for clients, this has never been a
> problem like it is above for our office. It was so frustrating that
> one weekend I came in, setup a new Windows Server 2003 system, new
> test active directory setup, but still when a non-domain member
> computer tries to access a share on either a domain server or domain
> member system, I'm still required to use 'my-domain\administrator' and
> 'mypassword'.

As expected.

>
> Can anyone be of help? I can't figure out if this is a DNS issue
> (appears to be...????) or if something needs to be changed in DHCP so
> that DHCP tells what domain control to authenticate against??
>
> Help!!

It is using NTLM to authenticate against whichever machine you are trying to
access. If accessing the DC, you need to supply which account you want to
use. If accessing a local machine (joined or not), you need to supply which
account to access it with. You can access a local machine (joined member)
from a non-member by supplying the domain\administrator account. It will not
use Kerberos authentication unless it is joined.

This is normal behavior.


--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer
(E-Mail Removed)

For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

Hello modem,

Cross-posting is the absolute correct solution so anybody can follow the
complete posting without switching between the NG's.

If you use AD for authentication you have to use domain\username. If you
like to use a local machine account you have to use computername\username.
SO it souynds for me correct what happens in your environment.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> I apologize upfront for the cross posting, but I'm not fully certain
> which group this post belongs in.
>
> Anyway I have a unique situation here at my office. We run a Windows
> Server 2003 R2 server which is the domain controller for an Active
> Directory domain that we use. Currently we use the server itself as
> well as a member server and a WinXP system (also AD member) for file
> storage which houses among other things, patches, updates, 3rd party
> software applications that we use when customers drop off their
> computers for repair.
>
> The purpose of our setup is to take customer computers, backup
> personal data, reformat the system, reinstall the OS, install AV
> software, patches, and finally restore the customers data. This setup
> been working fine for several years, but back in December when our own
> server crashed and involved a replacement and rebuilding a new active
> directory, this stopped functioning. Of course after that I rebuilt
> the domain, re-joined all of the above mentioned systems to the new
> domain.
>
> The issue that is happening is that any customer could bring any
> desktop or laptop that we could either via ethernet or wireless, we
> could access the shares by going to \\<server>\<share>. Of course the
> next box/prompt would be to login/authenticate of which I would use
> 'administrator' and then 'mypassword' and instantly gain access to any
> share on my network that I needed.
>
> That worked fine if I was accessing file shares on the XP file share,
> the Win2003 server file shares, etc. Previously it seemed when a non-
> domain PC accessed an AD member share, that member PC would
> authenticate against the Win2003 AD user database. However, things
> with this have changed.
>
> Now when I use any non-domain member PC or laptop and try to access a
> hidden or non hidden share on another member XP/2003 system, I still
> get the same prompt to login. But now when I use 'administrator' and
> 'mypassword' it rejects access until I use the login of 'my-domain
> \administrator' and then 'mypassword'. Once I use those credentials
> it lets me in just fine. However when logging into a share on the
> domain controller itself, then I can login the old way.
>
> When I try to login to an AD member file share, it appears that the AD
> member is NOT using the domain controller to authenticate the
> 'administrator' / 'mypassword' credentials I typed in, instead trying
> to authenticate against the non-domain PC I'm typing at. I suspect
> that is happening because the result is that I get a message that the
> following username and password are invalid and it indicates the
> username is 'ACER-065703\administrator' is not a valid logon. Where
> ACER-065703 is the PC name of this specific computer.
>
> Before I go further I know I may get some flame responses of "Active
> Directory isn't designed to work that way or let non-domain members
> in". And yes I know that. But the way our office is running things
> this is the best way for us to accomplish what we want to do. I've
> also scoured the internet via google trying to find a solution to this
> and have not been successful.
>
> The ironic thing, is when I have personally installed Windows Server
> 2003 Active directory networks for clients, this has never been a
> problem like it is above for our office. It was so frustrating that
> one weekend I came in, setup a new Windows Server 2003 system, new
> test active directory setup, but still when a non-domain member
> computer tries to access a share on either a domain server or domain
> member system, I'm still required to use 'my-domain\administrator' and
> 'mypassword'.
>
> Can anyone be of help? I can't figure out if this is a DNS issue
> (appears to be...????) or if something needs to be changed in DHCP so
> that DHCP tells what domain control to authenticate against??
>
> Help!!
>

Thanks for those replies, however as I suspected that the behavior
happening now is normal, this doesn't explain why this situation was
working differently for several years prior.

For example, Customer A would drop off a Windows XP Home OEM Dell
computer. I would take the computer to the workbench, connect the
Cat5e and would browse to \\domainpc1\backups and \
\domainpc1\downloads (this is an XP Pro domain member). XP Home
would prompt me for the login credentials so I would just use
"administrator" and "mypassword" and I would gain access instantly to
the shares. Never before the server crash was the credentials asking
for "domain\administrator" to login, this is what is puzzling me so
much.

Also, I have seen this same setup on two clients of ours that have AD
domains setup. Where I can take my laptop in, access a share on their
network and enter in the password for the administrator access by
using "administrator" and "password" and I gain access as well,
without using "theirdomain\administrator"

If the way our network here in the shop is a correct behavior of the
network, then why isn't it that way with our clients which was setup
nearly identical to ours?

Brad

"modem" <(E-Mail Removed)> wrote in message
news:bd48c595-f569-4f66-bcd8-(E-Mail Removed)...
> Thanks for those replies, however as I suspected that the behavior
> happening now is normal, this doesn't explain why this situation was
> working differently for several years prior.
>
> For example, Customer A would drop off a Windows XP Home OEM Dell
> computer. I would take the computer to the workbench, connect the
> Cat5e and would browse to \\domainpc1\backups and \
> \domainpc1\downloads (this is an XP Pro domain member). XP Home
> would prompt me for the login credentials so I would just use
> "administrator" and "mypassword" and I would gain access instantly to
> the shares. Never before the server crash was the credentials asking
> for "domain\administrator" to login, this is what is puzzling me so
> much.
>
> Also, I have seen this same setup on two clients of ours that have AD
> domains setup. Where I can take my laptop in, access a share on their
> network and enter in the password for the administrator access by
> using "administrator" and "password" and I gain access as well,
> without using "theirdomain\administrator"
>
> If the way our network here in the shop is a correct behavior of the
> network, then why isn't it that way with our clients which was setup
> nearly identical to ours?
>
> Brad


Good question. Possibly the local admin password was identical to the domain
admin password, or there was an identical account created locally that you
were logged on with?

Ace

I thought of that, but over the period of 3 years that we had the
server up and running, we encountered 200+ PC's we worked on in the
office. 98% were XP home that had a hidden 'administrator' account
with no password and had family accounts some with passwords, some
with not. Each one of those logged on without me typing the domain
\administrator to login. Where as the admin account on our server
here has 8+ characters in a combo which I doubt any other PC would
have.

It just seems like before, that when going to the file share on the
member XP workstation that the workstation validated the credentials
against the active directory accounts first, where as now it tries to
validate against the PC I'm logging in with and ignoring trying to
validate against the server.

Is there any known issue or way for a domain member PC to look at a
different place for authentication?

This has really got me puzzled for the fact that I am curious as to
finding an answer.

"modem" <(E-Mail Removed)> wrote in message
news:0fc0d1d3-6f55-407b-ae9a-(E-Mail Removed)...
>I thought of that, but over the period of 3 years that we had the
> server up and running, we encountered 200+ PC's we worked on in the
> office. 98% were XP home that had a hidden 'administrator' account
> with no password and had family accounts some with passwords, some
> with not. Each one of those logged on without me typing the domain
> \administrator to login. Where as the admin account on our server
> here has 8+ characters in a combo which I doubt any other PC would
> have.
>
> It just seems like before, that when going to the file share on the
> member XP workstation that the workstation validated the credentials
> against the active directory accounts first, where as now it tries to
> validate against the PC I'm logging in with and ignoring trying to
> validate against the server.
>
> Is there any known issue or way for a domain member PC to look at a
> different place for authentication?
>
> This has really got me puzzled for the fact that I am curious as to
> finding an answer.


The only thing I can think of is the security settings on the previous
domain were detuned/weakened for some reason, and/or it was an updated 2000
to 2003 domain where Everyone group had a play with the Pre-Windows 2000
Access Group.

What you are seeing is what really should be happening.

Ace