|
Posted by Ace Fekay [MVP] on April 22, 2008, 12:04 am
Please log in for more thread options
> > There are two ways to require smart cards for logon. You can
> > configure: * user account properties in Active Directory
> > * group policy for specific computers or groups of computers
>
> Either of those is acceptable. Since I have three administrators on
> two domain controllers, selecting user account properties is perfectly
> acceptable. We don't use domain administrator accounts on any
> machine other that domain controllers or for any purpose other than
> administering the domain controller, do our exposure to restricting
> those accounts to use of smartcards seems low.
>
>
> > There is no "require smart cards for administrators" setting
>
> I hope I didn't say that there was such a setting.
>
>
> > ...and there is no way to require smart cards depending on which
> > traffic arrives at particular network ports.
>
> >
http://www.microsoft.com/technet/security/guidance/networksecurity/securesmartcards/scpgch03.mspx
> > has some good information for you, please read through it. For a
> > variety of reasons, configuring smart card requirements on user (in
> > your case, administrator) accounts creates several problems, as
> > described in the guide. Instead, you should configure GPOs with the
> > smart card settings you want, then link those to the OUs containing
> > the computers (in this case, domain controllers) that you want to
> > require smart cards for. Note that this is for interactive logon
> > only, including remote desktop and terminal server; these settings
> > don't apply for access over the network.
>
> Assuming that the domain administrator user account was configured to
> only allow login to the domain controllers *and* was configured to
> require smartcards, the question is what APIs or applications that
> require authentication might continue to work with userid and
> password and no smartcard? In other words, I want to know what
> continued exposures would I have for a domain administrator whose
> credentials had been compromised, once smartcards are required for
> interactive login of his or her account and the account was
> restricted to login to the domain controllers only.
>
> > There's really nothing you need to do for network (non-interactive)
> > access. Remember, computers and users need to be able to contact the
> > domain controllers over the network for authentication purposes :)
>
> I was never proposing to remove any privilege for users or computers
> to access resources on a domain controller.
>
>
> > Now about my risk question... A password isn't something a person
> > can "steal."
>
> But of course a password can be stolen. A person can install a
> keyboard sniffer on a computer where the password is used, which
> would certainly by any reasonable meaning of the word be an example
> of stealing the password. A person can peek at someone typing in
> their password and remember it, which is certainly close to stealing
> it if they then go on to use it. A person can also find a note with
> the password written on it and then take it for their later use.
>
> No doubt one can design business processes to make all of these things
> harder to do. But you can never make any of them impossible. There
> should not be a debate that such kinds of theft are possible.
>
>
> > In your environment, under what circumstances could an unauthorized
> > person obtain the password? Domain admins legitimately possess the
> > password, so they already have permission to use it. By definition,
> > then, this means that any use of the password without permission is
> > by someone who isn't a domain admin and has somehow obtained the
> > password. Besides yourself, who else in your organization should
> > legitimately know this password? Do you trust these people not to
> > share the password?
>
> There are other cases besides just being a domain admin and not being
> one. For example, you might have a junior admin who you trust to take
> certain actions, but you want to be able to designate when that
> person has access. A very practical business process to grant such a
> person time-limited access to a domain controller would be to hand
> him his smartcard token, together with specific instructions on what
> to do, and then require the smartcard back when he is done.
>
> In any case, you are addressing the "why" and I was in my original
> question addressing the "what". I wanted to know does anyone make a
> relatively cheap product to secure specific machines. Every time I
> read an article like the one you referenced above, I walk away
> thinking using smartcards is going to be a $30K project involving a
> lot of custom systems integration, involving someone who knows a lot
> of about certificates. What I was hoping for was a sub $1000
> out-of-box product with two readers included that I could just
> install, generate certificates directly into the smartcard with that
> product, and then secure the smartcards. Once I get into issues
> like installing a certificate server, figuring out how to get one of
> its certificates onto some generic smart card, mixing and matching a
> reader from one vendor with a smartcard from another vendor, etc, it
> starts to feel like a project with a long learning curve. Since I
> am both time and budget constrained, knowing what can be done cheaply
> and quickly is important.
> Does nothing simple for securing a small number of servers exist?
>
Take a look at this that doesn't need a device, but rather works off a USB
'key,' which would reduce the price.
https://www.cryptoken.com
Order an eval:
https://www.cryptoken.com/order/2.1/orderEvalKit_step1_welcome.php?referrer=mailing
Or fingerprint:
Digital Persona Fingerprint Authentication:
http://www.digitalpersona.com/bannerLanding/g.php?gclid=CK_b9Mrj7ZICFQurPAodMCHFgQ
Ace
| 
XML Sitemap