Generating 540 or 4624 events

[Nicklebon]

I've got a a customer that is using a single sign on product that uses agents installed on the customer's domain controllers. This works fine accept for one scenario. When the customer transitions from a wired to wireless connection or vice versa. We have determined the reason for this is that the DCs are not getting Windows logon events ie 540 on 2003 servers or 4624 on 2008+. The users have files shares mapped onto member servers but refreshing those is not hitting the DCs.

Do you folk know of a way to ensure hitting a domain resource generates a logon event on a DC without directly mapping a resource on a DC. If it matters there are 50 domain controllers and around 200 member servers spread all over 48 states.

 

[Wrench00]

I've got a a customer that is using a single sign on product that uses agents installed on the customer's domain controllers. This works fine accept for one scenario. When the customer transitions from a wired to wireless connection or vice versa. We have determined the reason for this is that the DCs are not getting Windows logon events ie 540 on 2003 servers or 4624 on 2008+. The users have files shares mapped onto member servers but refreshing those is not hitting the DCs.

Do you folk know of a way to ensure hitting a domain resource generates a logon event on a DC without directly mapping a resource on a DC. If it matters there are 50 domain controllers and around 200 member servers spread all over 48 states.

Its because you need to add the wireless Networks/subnets (if they are different from wired)to your sites. The AD doesn't know where to allocate the requests to.

Besides the normal DHCP/DNS assignments aside.

 

[Nicklebon]

Its because you need to add the wireless Networks/subnets (if they are different from wired)to your sites. The AD doesn't know where to allocate the requests to.

Besides the normal DHCP/DNS assignments aside.

The customer uses the same subnets for wired and wireless. Please note both and wired and wireless work flawlessly. The AD integrated DNS works just fine.

The problem is when the user transitions from to the other the DC does not receive the 540/4624 logon event. The machine that has the mapped file share receives it.

 

[Wrench00]

The customer uses the same subnets for wired and wireless. Please note both and wired and wireless work flawlessly. The AD integrated DNS works just fine.

The problem is when the user transitions from to the other the DC does not receive the 540/4624 logon event. The machine that has the mapped file share receives it.

Sorry I misunderstood about the who is getting the event. So the member server generates the event id when switching between the connection based wired/wireless?
The only reason why I think this is happening is because when you are wired the SMB session hasn't expired from the old connection before you switch to the wireless connection at which a new NTLM/Kerberos id is being generated based on

Caller User Name:
Caller Domain:
Caller Logon ID:
Caller Process ID:
Transited Services:
Source Network Address:
Source Port:
Possibly new MAC address( I know AD generates GUID on mac address of the server)

As for why its not happening the other way around I am not sure unless some one has GPO that is set to not log the event.

SMB session(NTLM) can be changed. Default is 15 Minutes but lests say you have the dreaded red x problem on network drives you actually need to tweak that setting.

 

[Nicklebon]

2 scenarios:

A. Client and a FS that is also a DC

1. Client logs in event 540 sent on DC
2. Client switches from wired to wireless
3. Client opens mapped drive
4. Event 540 seen on DC

B. Client File Server and Domain Controller

1. Client logs in
2. Event 540 seen on DC
3. Client switches from wired to wireless
4. Client opens mapped drive
5. Event 540 seen on File server and not the DC

In each case I've left out the DNS updates that occur as expected. We did have to disable DNS caching on the DCs due to even though the DNS service was getting the updates the Windows OS was caching DNS and never actually querying the DNS service. This was done to avoid the performance hit that would be seen if we reduced the TTL at the server level.

We need a way to trigger a 540/4624 on the DCs when the user transitions otherwise the SSO agent never sees the transition and the user gets the incorrect web filter profile.

 

[Wrench00]

2 scenarios:

A. Client and a FS that is also a DC

1. Client logs in event 540 sent on DC
2. Client switches from wired to wireless
3. Client opens mapped drive
4. Event 540 seen on DC

B. Client File Server and Domain Controller

1. Client logs in
2. Event 540 seen on DC
3. Client switches from wired to wireless
4. Client opens mapped drive
5. Event 540 seen on File server and not the DC

In each case I've left out the DNS updates that occur as expected. We did have to disable DNS caching on the DCs due to even though the DNS service was getting the updates the Windows OS was caching DNS and never actually querying the DNS service. This was done to avoid the performance hit that would be seen if we reduced the TTL at the server level.

We need a way to trigger a 540/4624 on the DCs when the user transitions otherwise the SSO agent never sees the transition and the user gets the incorrect web filter profile.

The Fileserver is re-authenticating the user because the users GUID has changed. Reason why you happen to see the Event in scenerio A is because FS and DC are on the same server.
Scenerio B is happening because the DC is not actually doing the re-authentication but the file server is, because its generating a new NTLM/Kerberos "handshake" between FS and Client after the initial logon.

IE.
Client Logs in Authentication to DC for Credentials check (Not a FS check)
FS and DC already have a in place NTLM/Kerberos authentication
FS grants access.
User switches Network Connection (MAC) FS recognizes a new Hash/Handshake sends request to DC for verification but there is already an existing relationship between FS and DC thus no event. (Remember the User already is logged in)


The only way I can think of generating the event on a DC in scenerio B is
1. Make a DFS and your DC is the Naming Server. (Best Option I think) Point everything to DFS for file shares.
2. Shorten Authentication between FS and DC which might increase network overhead on your network FS because it will be asking all the time for new Hashes/Handshakes. It will also generate a boat load of events and even this I doubt will solve your problem.
3. There might be a setting in GPO that forces FS to ask for DC authentication every time a user changes Hash/Handshake.
4. Force Log off when switching networks.

 

[Nicklebon]

It is not automated but I think I've got it. I'm going to suggest the customer just put an icon the user's desktop named "IP switch" that does the following

net view \\%LOGONSERVER%

This generates 4624s on 2008 and I'll assume 540s on 2003.

Thanks all

 

[Wrench00]

It is not automated but I think I've got it. I'm going to suggest the customer just put an icon the user's desktop named "IP switch" that does the following

net view \\%LOGONSERVER%

This generates 4624s on 2008 and I'll assume 540s on 2003.

Thanks all

I didn't think of that but thats pretty good. If you want to take it a step forward I suggest doing a scheduled task (windows vista or higher) that you can attach to specific event (network disconnect) or timed. You can distro it via gpo.

http://superuser.com/questions/262799/how-to-launch-a-command-on-network-connection-disconnection