|
Posted by JCB MCSE wannabe on May 30, 2005, 8:55 pm
Please log in for more thread options Thanks once again. I will watch out for the IPSec conflicts you cautioned
about as well.
This dialog has been most helpful.
--
JCB59
"Steven L Umbach" wrote:
> Reply in line.
>
> > Steven:
> >
> > I was so close! I surmised that the wireless was somehow the root cause
> > of
> > the authentication failures, because I could watch the NIC calling for a
> > DHCP
> > lease renewal AFTER I logged on. I greatly appreciate you taking the time
> > to
> > provide a thoroughly descriptive answer. I don't know if you read my
> > profile, but I am new to networking and have gained experience with much
> > of
> > the required skills needed to pass the MCSE certification exams.
> > Thankfully,
> > I have the resources to build a labbing network to get much-needed
> > hands-on
> > time with the Server product.
> >
> > But if you don't mind, let me address your replies on a point-by-point
> > basis, as you have stimulated further thought and need for clarification
> > on
> > my part.
> >
> >
> > --
> > JCB59
> >
> >
> > "Steven L Umbach" wrote:
> >
> >> When you joined your computer to the domain your wireless network card
> >> was
> >> initialized and working properly. However when you reboot your computer
> >> the
> >> network card does not initialize fast enough in order to have the
> >> computer
> >> authenticate to the domain.
> >
> > This is absolutely correct. However, isn't there a Group Policy setting
> > (or
> > Local Policy, as the case may be) which will delay authentication until
> > the
> > network is ready?
>
> There is a Group Policy setting for fast network optimization for windows XP
> Pro that usually [there are exceptions as stated in link below] causes a
> user to be logged on with cached credentials, though it does not always seem
> to work with wireless network cards that take a long time to access the
> network. I have the same situation with my laptop and it's D-link wireless
> card. I also have an Intel network adapter and WAP that does not have this
> problem and even works well with 802.1X EAP-TLS for domain logon.
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;305293&Product=winxp
>
> >> The computer does not necessarily need to
> >> authenticate to the domain resources in order for a user to access domain
> >> resources particularly if cached logons are enabled. With cached logons
> >> you
> >> are logged with cached domain credentials to the local computer. When you
> >> try to access domain shares while logged on with cached credentials you
> >> are
> >> denied access until you can authenticate to a domain controller as a
> >> user.
> >> By the time you attempt such your network card is probably initialized
> >> and
> >> thus you can access the domain controller, be authenticated, and then
> >> access
> >> a domain share.
> >
> > There is a tremendous amount of information you have provided above; let
> > me
> > see if I fully understand the implications:
> >
> > - I understand what you mean about cached domain logons. In fact, I have
> > just set the policy value to zero (from 10) for various reasons. But what
> > you said next caught me off guard - that is, you are suggesting that even
> > though I am not INITIALLY authenticated, once the NIC is fully
> > initialized, I
> > will SUBSEQUENTLY be initiated? Is this correct? If so, it would seem
> > that
> > the problem I have observed would EVENTUALLY disappear upon subsequent
> > invocations of the Netdiag command - is this correct??? I CAN access net
> > shares via a UNC path on the machines that show the initial Kerberos
> > error.
> > Hmmmm....
> >
>
> In addition to disabling cached logons also disable fast logon optimization.
> Another thing that could be happening is that the network connection is not
> happening fast enough for computer authentication but it is ready for user
> authentication which alsways happens after the attemp to authenticate the
> computer account. If cached domain credentials are disabled and the computer
> can not contact a domain controller when the user attempts to logon the
> domain then the user authentication will fail and the users will get a
> message that a domain controller can not be contataced or something to that
> effect. Try logging onto the domain when the domain controller is either
> shut down or disconnected from the network to see what happens. If cached
> logons are allowed then yes the user can be authenticated to the domain
> after a domain cached logon. Netdiag may still show kerberos errors because
> the user has authenticated via lm/ntlm/ntlmv2 since kerberos authentication
> failed or because the "computer account" does not have a kerberos ticket. In
> most cases [ipsec a possible exception] kerberos authentication is not
> needed to access domain resources as long as the client and server use a
> common authentication method for lm/ntlm/ntlmv2.
>
> >
> >
> > Another downside of not having the computer account
> >> authenticated to the domain is that the computer configuration Group
> >> Policy
> >> will not be applied/refreshed at startup.
> >
> > - Dammit! I thought I was going crazy. Now I understand why certain
> > (computer) policy changes I made were not applied...UNTIL normal GP
> > refresh
> > had occured!
> >
> Group Policy is always applied or refreshed at startup for computers and
> logon for users. Certain Group Policy elements such as Software Installation
> can only be applied at startup/logon and redirection of folders can only be
> done at logon.
>
> >>
> >> You should have logging of account logon events enabled in Domain
> >> Controller
> >> Security Policy which it is by default in Windows 2003 and also enable
> >> auditing of logon events on your domain computers which may also provide
> >> helpful information including if cached logons are being used. The set
> >> command when run on a domain computer will also show the authenticating
> >> computer/domain controller.
> >
> > - A user logging on locally will generate a "Logon" event, while a user
> > logging on to the domain/network will be authenticated by a DC and
> > generate
> > an "Account Logon" event. BUT, what about the MACHINE account? Will
> > there
> > be an entry in the appropriate security logs indicating Logon vs. Account
> > Logon? If so, will the log(s) first show a Logon event followed by an
> > Account Logon event, if my machine is SUBSEQUENTLY authenticated (as per
> > my
> > comments above)
>
> Computer account account logon events for a domain computer logon to the
> domain will show only in the security log of a domain controller if you have
> auditing of account logon events enabled which it is by default. I am not
> sure offhand if a computer account will try to authenticate after failuer to
> do so at the intitial startup. That is something you can look for in your
> domain controller security log. It may happen if the computer tries to
> engage in an ipsec negotiate connection which would require computer
> authentication.
>
> >> While kerberos is the default authentication protocol of choice, fallback
> >> can be done to lm/ntlm/ntlmv2 in a Windows 2000/2003 domain. Kerberos
> >> failure is not usually as problematic as is problems with the computer
> >> account as shown by errors/failed test with trust/secure channel as shown
> >> with netdiag. Kerberos authentication for the "computer" is however
> >> required
> >> for domain negotiation ipsec policy using ESP/AH if using default
> >> authentication for the ipsec policy.
> >
> > - Now I understand the IPSec negotiation errors I have been seeing with
> > NetMonitor.
>
> Be careful with ipsec policy. Most do not understand [too little
> documentation] that domain computers and domain controllers can not
> communicate with ipsec AH/ESP due to the fact that the domain controller is
> also the kerberos distribution center. Domain controllers must be exempt
> from ipsec policies for the domain that involve domain computers or all
> sorts of problems can occur. Refer to the KB article below for more details
> and to the Windows 2003 Deployment Kit chapter on ipsec which is a free
> download at the second link.
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q254949
>
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/DepKit/119050c9-7c4d-4cbf-8f38-97c45e4d01ef.mspx
>
> >
> > Also keep in mind that the netdiag
> >> /debug switch may also give more detailed info on why a test failed.
> >>
> >> I bet that if you hard wire one of your domain computers to the network
> >> that
> >> you will not see the problem with kerberos anymore.
> >
> > - You are correct!
> >
> > Also since you are
> >> interested in troubleshooting you will find packet sniffing very helpful
> >> for
> >> a problem such as yours or many other problems. In your case monitoring
> >> packet activity on the domain controller while a domain computer is
> >> booting
> >> up will tell a lot, particularly if you have a capture of a successful
> >> domain computer account logon to compare to. Windows 2003 Server has the
> >> built in netmon though I personally much prefer Ethereal which is free.
> >> Also
> >> dns configuration for the domain MUST be correct or all sorts of problems
> >> will ensue. The first link below is a good quick read on dns for an
> >> Active
> >> Directory domain and the second is on troubleshooting kerberos errors
> >> which
> >> can be displayed in the security logs of domain controllers. --- Steve
> >>
> > - I have not experienced many DNS errors (probably because I chose an
> > AD-integrated DNS implemnentation - which seems to be quite simple). One
> > annoying problem, confirmed by monitoring, was that after removing Root
> > Hints
> > from the DNS server and disabling recursion for the domain (NOT the
> > server),
> > my server was STILL resolving on the internet. I had configured
> > Forwarders
> > to my ISP's DNS servers for "all other domains", so as to hide my server
> > (as
> > much as possible) and to put the work of resolution off on my ISP (or so I
> > thought). But each time I would reboot the server (which I do a lot for
> > labbing, probably FAR more than would ever be done in a production
> > environment), the Root Hints table was persistently repopulated.
> > Apparently,
> > this table cannot be void, so I entered my SOA server as a root hint.
> > This
> > has fixed the problem, but was certainly NOT an intuitive solution! (at
> > least
> > for a newbie like myself)
> >
> > Thanks for you spot-on technically accurate response. If you have any
> > thoughts on the points I raised above, I'd love to learn more from you.
>
> You can still have dns problems with an AD domain. The main issue is to
> NEVER include an ISP dns server in the preferred server list in the tcp/ip
> properties or DHCP scope of any domain computer or any computer you want to
> join to the domain in which case your computers may be trying to locate the
> domain _srv records on the ISP dns server and fail. I would not worry about
> the root hints table. If you have disabled recursion for the domain then
> your dns server should be a slave to your ISP dns server and never use root
> hints which will work fine as long as your ISP dns servers respond to dns
> requests from your network. Even if your dns server does use root hints your
> dns server should be at very little risk as long as your firewall is
> blocking incoming destination port 53 udp/tcp to your dns server.
>
> It looks like you are well on your way to learning material for the MCSE as
> you want to learn "hands on" and have a thirst for knowledge which is a huge
> plus. --- Steve
>
>
> > Many thanks, JCB
> >
> >
> >> http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B291382
> >>
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx
> >>
> >>
> >> > NOTE: This post was incorrectly posted under "Access Security"
> >> > previously.
> >> > I misinterpreted the topic as resource access, not MS Access database
> >> > product...oh well!....
> >> >
> >> >
> >> > I am new to networking. I recently built a small AD-integrated DNS
> >> > domain
> >> > network for labbing purposes using my TechNet Plus Server 2003 Ent. OS.
> >> > The
> >> > single server is also running DNS and DHCP. All of my clients (yeah,
> >> > all
> >> > SIX
> >> > of them - I did say SMALL!) are running XPsp2. Hosts connect to the
> >> > network
> >> > using wireless cards through a linksys NAT-enabled router/switch. The
> >> > server
> >> > is hard wired to one of the switch ports on the linksys. I am using
> >> > 128-bit
> >> > WEP encryption
> >> > and further control access using a MAC table of allowed hosts on the
> >> > wireless. Three machines are workstations and three are
> >> > laptop/portables.
> >> >
> >> > I successfully joined the client machines to the domain. They receive
> >> > DHCP-assigned IP addresses. However, when I run the Netdiag commmand,
> >> > I
> >> > receive PASSING results for all tested parameters, EXCEPT the Kerberos
> >> > test
> >> > which gives a: " [FATAL] Kerberos does not have a ticket for
> >> > host/mymachinename.mydomainname" result.
> >> >
> >> > The strange thing is that immediately after I joined the machines to
> >> > the
> >> > domain and ran Netdiag, a PASSING Kerberos result is obtained.
> >> > HOWEVER,
> >> > once
> >> > the machines are restarted, the Kerberos test yields a consistent
> >> > FAILED
> >> > status. With Server2003/XP, I thought Kerberos v.5 was the default
> >> > authentication protocol. If my machine is not being authenticated, how
> >> > come
> >> > I can still access domain resources? Should my audit logs show a
> >> > "logon"
> >> > event instead of an "account logon" event if my machine is not
| 
XML Sitemap