|
Posted by Tim on May 31, 2005, 10:38 pm
Please log in for more thread options
Dear folks,
One thing I noticed is that the start setting for Wireless device driver
tends to be "3" which is something like User Logon. I changed mine to 2
(something like ~= as a service) with no adverse effects (dynalink and intel
2200bg with a d-link WAP) and setup 802.1x. With 802.1x and Windows Wireless
zero config (IE not a 3rd party user world application that does not start
until logon), the wireless connection can kick off when it is ready. This
was confirmed in the server event logs with IAS (i set that up as the radius
server for the WAP) reporting that the machine is authenticating prior to
logon and the errors you are discussing disappeared - almost totally I
think. If I logon too quickly after say the laptop boots then I think errors
can still occur as the machine is too busy to get all the above done prior
to me interfering with what it is doing by logging on. So, may be a few
tweaks on service dependancies and so on and it can go 100%.
The thing that now happens is a slightly slowed down equivalent of LAN
machine authentication - I suspect there may be one warning left in the
event log. When I as a user logs on the default option of re-authenticating
as an ordinary user kicks in and takes over from the machine authentication.
With the Intel 2200BG this has been totally reliable, the dynalink has
settled down now too I think (tinkered with firmware, drivers and "things").
Previously it was as you are describing / experiencing - a pregant pause
while the network sorts itself out and a double click on a network link of
any sort will turn into a tedious wait while the wireless things would do
their stuff.
HTH.
- Tim
> 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
>>> > authenticated?
>>> >
>>> > Does anyone have an explanation? I would prefer guidance on how to
>>> > efficiently troubleshoot this problem and not just a "here, do this"
>>> > solution. The REAL problem is I don't yet have the troubleshooting
>>> > skills
>>> > to effectively address the apparent Kerberos authentication failures.
>>> >
>>> > Any help would be appreciated.
>>> >
>>> >
>>>
>>>
>>>
>
>
| 
