Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : There are 5 different ways you can logon in Windows. We call them logon types. The Windows Security Log lists the logon type in event ID 4624 whenever you logon. Logon type is what allows you to determine if the user logged on at the actual console, via remote desktop, via a network share or if the logon is connected to a service or scheduled task starting up. The logon types are Type Description Allow right Deny right 2 Interactive logon at keyboard and screen of system SeInteractiveLogonRight Allow logon locally SeDenyInteractiveLogonRight Deny logon locally 3 Network i.e. connection to shared folder on this computer from elsewhere on network SeNetworkLogonRight Access this computer from the network SeDenyNetworkLogonRight Deny access to this computer from the network 4 Batch i.e. scheduled task SeBatchLogonRight Log on as a batch job SeDenyBatchLogonRight Deny logon as a batch job 5 Service Service startup SeServiceLogonRight Log on as a service SeDenyServiceLogonRight Deny logon as a service 10 RemoteInteractive Terminal Services, Remote Desktop or Remote Assistance SeRemoteInteractiveLogonRight Allow logon through Terminal Services SeDenyRemoteInteractiveLogonRight Deny logon through Terminal Services There are a few other logon types recorded by event ID 4624 for special cases like unlocking a locked session but these aren t real logon session types. Knowing the session type in logon events is great but you can also control users ability to logon in each of these 5 ways. A user account s ability to logon is governed by 5 user rights found in group policy under Computer Configuration Windows Settings Security Setting User Right Assignments. There is an allow and deny right for each logon type. In order to logon in a given way you must have the corresponding allow right. But the deny right for that same logon type takes precedence. For instance, in order to logon at the local keyboard and screen of a computer you must have the Allow logon locally right. But if the Deny logon locally right is also assigned to you or any group you belong to, you won t be able to logon. The table below lists each logon type and it s corresponding allow and deny rights. Logon rights are very powerful. They are your first level of control determining whether a user can access a given system at all. After logging in of course their abilities are limited by object level permissions. Since logon rights are so powerful it s important to know if they are suddenly granted or revoked and you can do this with Windows Security Log events 4717 and 4718 which are logged whenever a given right is granted or revoked respectively. To get these events you need to enable the Audit Authentication Policy Change audit subcategory. Events 4717 and 4718 identify the logon right involved in the Access Granted Access Removed field using a system name for the right as shown in corresponding column in the table above. The events also specify the user or group who was granted or revoked from having the right in the Account Modified field. Here s an example of event ID 4717 where we granted the Access this computer from the network to the local Users group. System security access was granted to an account. Subject Security ID SYSTEM Account Name WIN-R9H529RIO4Y Account Domain WORKGROUP Logon ID 0x3e7 Account Modified Account Name BUILTIN Users Access Granted Access Right SeNetworkLogonRight There s just one problem. The events do not tell you who which administrator granted or revoked the right. The reason is that user rights are controlled via group policy objects. Administrators do not directly assign or revoke user rights on individual systems even if you modify the Local Security Settings of a computer you are really just editing the local group policy object. When Windows detects a change in group policy it applies the changes to the local configuration and that s when 4717 and 4718 are logged. At that point the user making the change directly is just the local operating system itself and that s why you see SYSTEM listed as the Subject in the event above. So how can you figure out who a granted or removed the right You need to be tracking group policy object changes is a topic I ll cover in the future.

Les mots clés de la revue de presse pour cet article : security
Les videos sur SecuObs pour les mots clés : security
Les mots clés pour les articles publiés sur SecuObs : security
Les éléments de la revue Twitter pour les mots clé : security





Les derniers articles du site "Security et al" :

- Vulnerability Scanning Done Right
- Seven Steps to Designating Owners of Unstructured Data
- Comparison SQL Server Audit vs. SQL Trace Audit for security analysts
- SolarWinds Makes It Easy to Detect SharePoint Breaches with Integration to LOGbinder SP
- Monitoring File Permission Changes with the Windows Security Log
- Cool Stuff at RSA
- Elephants and Irony at RSAC
- In search of great technology at RSAC among all the noise filtering
- Auditing File Shares with the Windows Security Log
- Pay Attention to System Security Access Events

---

S'abonner au fil RSS global de la revue de presse

---