Show n Tell Friday
Yeah, okay, I'm a day late again. Sue me.
There's a discussion over at MBR's blog again (am I just living there lately or what?) regarding the F5 key for clearing the password in Notes. Apparently, it's under consideration to remove this capability in Hannover. I think there are all kinds of reasons not to do this, and I provided quite a list over there but there's one that's particularly important to me.
The alternative approach being proposed is to, instead of clearing credentials in Notes, simply lock the OS. My concern is that an operating system like Windows is inadequate to properly secure the Notes environment, since any Active Directory administrator can bypass the screen lock. Paul Simpson disagrees with me:
Windows Administrators can NOT unlock a locked workstation. All they can do is force a log off or shut down of a workstation, which kills all open applications in the process. Unlocking a locked workstation would violate basic security principles and be very bad even by Microsoft standards.
So today's Show n Tell is very simple -- how to unlock a Windows workstation when you're an active directory admin and get access to the running application.
All you have to do is... change the user's password on the PDC!
Feel free to try it in your own environment. I just did it in my own active directory domain here (yes, I do run an MS network -- you didn't think I was some kind of zealot, did you?) I logged a workstation into the domain, then locked it, then went to the PDC and changed that user's password to "password", then went back to the workstation and could log in with "password." It's just that simple.
Now, in anticipation of someone saying "yeah, but you would reveal the hack when the user's password was changed when they tried to log back in," my answer is: sure. But how many times do users call the helpdesk to get their password reset because something happened on a domain controller? And have any of you ever tried out l0phtcrack? What about backing up the user information before making the password change and then restoring it when the deed was done? I'm not even a skilled active directory administrator and I can think of half a dozen approaches off the top of my head to mask this action. Imagine what someone who knew the product could do!
An active directory administrator would typically be able to access all the network file shares and printers in the enterprise. He might even have elevated access to proxy servers and logs. He probably does NOT have access to confidential financial records, HR reports, encrypted email and purchase order approvals. However, all of these are prime candidates for Notes applications where a CEO probably WOULD have elevated access.
Should your active directory admins have that much power?
Comments
Posted by Chris Linfoot At 03:46:16 AM On 06/30/2006 |
Posted by Richard Schwartz At 11:02:05 AM On 06/30/2006 |
Posted by Andrei Kouvchinnikov At 11:03:15 AM On 07/09/2006 |
Just to remind us all where this discussion started... It's about locking Notes (with F5 or anything else).
The Notes lock must stay as it can easily and very clearly be demonstrated that the simple username/password authentication in an AD environment is simply not robust.
Posted by Chris Linfoot At 01:26:36 PM On 06/30/2006 |
In any case, you are right that Windows administrators have a lot of power in the Windows AD domain. Large companies mitigate this by restricting full administrator privileges to a very select number of people and delegating abilities (e.g. password reset) to others and using auditing and logging to provide an audit trail.
Posted by Paul Simpson At 09:24:38 AM On 06/30/2006 |
I, too, was intrigued, so I did Nathan's test myself. It works exactly as he described. I read through the articles you provided and they bear this out.
Here's what is going on: You log in and your credentials are cached. You lock your session, then log back in. Your cached credentials are checked first. If they match, you're in. If they don't, it checks the domain controller to see if what you entered matches what's on the domain controller. If that second lookup works, you're in. This is how Nathan and I were able to change the password on the domain controller and log in.
You can bypass the cache comparison by using a GPO or changing Registry settings, but you cannot prevent the lookup to the domain controller. The lookup to the domain controller is considered to be more stringent security than using cached credentials.
Posted by Charles Robinson At 11:06:51 AM On 06/30/2006 |
It's not going to work if the user logged into a LOCAL account instead of the active directory, but hopefully your corporate directory isn't run that way. Even if it were, it's likely that an AD administrator would have the ability to remotely administer that machine and reset the local password as well.
There's nothing unusual in any way about my configuration settings as far as I know. It's pretty much an out-of-the-box install.
Honestly, there's all kinds of weird tampering you can do in an AD environment. Like causing the fallback to the last cached password on a local machine by unplugging it from the network, then plugging it back in after login. The central problem is that Notes security, which is credentialed and based on 2-factor encryption token access, shouldn't be subject to the much simpler user/password model that most OS's stick us with. If you were looking at a SmartCard setup for your network, then ok. But simple AD environments are almost invariably weaker than the same Notes environment.
It's the same reason that in the Domino world, available security from the browser client isn't adequate for digital signature applications!
Posted by Nathan T. Freeman At 09:41:35 AM On 06/30/2006 |
Having said that, you piqued my curiosity so I did a little bit of ndigging! The following articles illustrate that by default when unlocking a workstation the password is compared to a hash stored in memory and not the domain controller. Of course, it's possible to change this default using group policy to force a domain controller to be contacted in order to unlock a workstation--perhaps this is how your AD domain has been configured?
Regardless, this bit of research has illustrated a completely unrelated but nonetheless extremely interesting point to me! Although this setting can ostensibly be used to increase security, it actually could potentially DECREASE security by allowing the kid of attack you illustrate in your blog entry (i.e. an administrator resetting a password then unlocking the workstation)!
Looking forward to further discussions. See you on MBR's blog!
-Paul
http://searchwinit.techtarget.com/tip/0,289483,sid1_gci968000,00.html
http://technet2.microsoft.com/WindowsServer/en/Library/08e505ca-0e68-458d-b85d-60a6a37dc9271033.mspx?mfr=true
http://support.microsoft.com/?id=281250
Posted by Paul Simpson At 09:53:34 AM On 06/30/2006 |
In terms of companies that utilize single sign-on, it is not necessarily enforced for Notes. Users have the option of creating a different password for Notes. Obviously that disables SSO for that user. Locking the OS bypasses that user's choice of a separate password for Notes.
Beyond that scenario, hitting 'F5' today effectively logs out of Notes in an SSO environment--even if the Windows and Notes passwords match. The Notes password must be entered before any further Notes activity is available.
So even in an SSO environment, changing 'F5' to "lock" the OS instead of Notes would open a hole that doesn't exist now.
Of course an administrator with access to AD may well have access to Notes IDs...but that's an organizational security choice/issue, not one inherent in the software.
All of that said, I tend to lock my workstation/OS when I leave my desk...rather than locking Notes. That's not really the point though. For those that make use of the extra layer of security, it shouldn't be taken away.
Here's what I would find useful (not sure it's possible...but it would be useful):
- hook into the OS lock, and lock Notes automatically (based on user preference). Sametime client catches the OS lock, so the Notes client should be able to as well.
- Ctrl-Alt-F5 (or similar combination) to lock Notes *and* the OS
- upon unlocking the OS, attempt to use the OS password for Notes
- outside of unlocking the OS, still require the user to enter their password to unlock Notes (even in SSO environments, just like today)
Benefits:
- single set of keystrokes to perform a dual action
- user protected from AD admin gaining access to Notes by changing the Windows password (Windows may unlock, but Notes wouldn't)
- users in SSO environments with matching passwords gain an extra level of security over today's security
Anyway, enough rambling. Main point, Notes lock shouldn't be removed...
- Rod
Posted by Rod Stauffer At 05:39:13 PM On 07/01/2006 |