Logon Session (Console & RDP) Tracking Notes

A few notes about how Windows handles session creation/switch when I was writing an app to track user logon time. Maybe useful for somebody.

Content:
1. Observation
2. How to handle properly

=========================================
=  Observations
=========================================
disconnect from a remote session: remotedisconnect

logoff from console: logoff(user), consoledisconnect(user), consoleconnect(system)

(a system logon screen session can be identified by its "logonUI.exe" process, a subsequent logon will take over this session - meaning same session nuber. In this case, it will be only one event: sessionLogon)

lock a session: sessionLock

switch to an existing session: consoledisconnect(1st user) -> consoleconnect(system) -> consoledisconnect(system) -> consoleconnect(2nd user) -> unlock(2nd user)

unlock directly from orignal screen: consoleUnlock
if "switch user" clicked, then unlock: consoledisconnect(user)->consoleconnect(sytem takes over) -> consoledisconnect(disconnect system)-> consoleconnect(original user) -> sessionunlock(original user).

switch then a new logon: lock old user(sessionlock) -> disconnect old user(DisconnectConsole) -> System takes over(ConsoleConnect) -> new user takes over (sessionLogon)

remote disconnect: RemoteDisconnect

remote New connect:
-> remoteConnect(?)
-> sessionLogon
remote REconnect (existing logon sesseion somewhere):
-> remoteconnect(system)
-> if(existing was on console and open)
-> existingSessionDisconnect(user)
-> then system has to spawn a new session to take over (sessionConnect)
-> remoteDisconnect(system)
-> remoteconnect(user)


=========================================
=  How to handle properly
=========================================
There are many session switch that are very confusing at the first sight. For example, for a simple user switch, their may be up to 5 session switch events. The key thing to remember is whethre user has an existing session already.

- once a user obtained session #, he/she keeps that same session # unles she/he logs off. None other session switch events will change this owning relationship;
- Logically, user gets a new session # only when she/he logon
- If a user connects back on a same session or unlock a same session that he obtained prior, then only one switch envent, sessionUnlock or session logon will be fired;
- if a user takes a brand new session, or take session from others, then ConsoleDisconnect/connect will happen multiple times. Basically, TS has to break existing session from another user, connect under System, disconnect System session, then finally users takes the session

AD CA basic - study notes

1. There are 3 snapins for certificate-related management
1. on client, there is Certificates snappin, this manages the actual certificates
2. on server, you have CA snapin and Certificate Templates snapin
2. Just because you have a certificate template, doesn't mean CA is going to use it
3. In order to issue a certain type of certificate, you have to let CA know that you want to issue that type of cert:
1. In CA snapin, right click server name, New Certificate Template To Issue
2. To check the current template that your CA can issue, click on "certificate templates"
4. To manage your templates (in use/not in use), in CA snapin, expand CA server name, right click "Certificate Templates", select manage
5. After #3, you are in "Certificate Templates" snapin
1. Templates listed in here can be in use or not in use, depending on if you have perform #3 above
2. You can directly publish a built-in template, but more typically, you should clone a template, make change on clone, then publish it (not a clone any more since we have made changes)
6. For client to request:
1. on a client machine, open Certificate snapin
   Optionally you can use IIS Admin Console or certreq command line
2. Generate a request, send it to CA admin
3. CA admin approves it
4. Client enrolls the cert
7. You can automate #6 by enabling auto enrollment in group policy
8. Enterprise CA vs. Standalone CA
1. standalone CA doesn't have certificate templates
2. standalone doesn't support auto-enrollment
3. 
   

KMS, host keys, client keys, etc.

1. One KMS can host multiple host keys - for example, it can host both Windows 2012 & Office host keys at the same time
2. Host keys are confidential info for companies who bought the license; while client keys are publicly available from Microsoft's website. Client key for a product is same for all companies who chose to use KMS activation.
3. Higher host keys is inclusive in that it covers older, lower products in the same product family. For example, once you install Windows Server 2012 Enterprise Edition, you won't need separate keys to cover standard edition or Windows 2008 servers. The same key covers all.
4. Procedure that can solve vast majority of activation issues in KMS environment
1. make sure DNS is working (can resolve KMS host name correctly), or just use IP address in below commands
2. check if client is using KMS activation
1. slmgr -dlv
2. it should show in output that this is a KMS client. If it's not a KMS type client: 
1. slmgr -upk
2. slmgr -ipk "product key of the OS version/edition". 
   You can google and find the product key
3. check if your client can resolve KMS SRV record
   ping _vlmcs._TCP.yourDomain.name
   if not resolving, you can manually add this record in DNS
   if resolving, your activation should work. Go to the verification step
4. If you don't want to use SRV record, you can also manually tell OS where to find KMS host
   slmgr -skms "A record of KMS host" or
   slmgr -skms "IP of KMS host"
5. verify and active 
   slmgr -ato