smart cards planning

8/9/2019 Smart Cards Planning

1/56

The Secure Access UsingSmart Cards Planning

GuideVersion 1.1

Published: June 2005 Updated: May 2007

For the latest information, please see

microsoft.comtechnetSolutionAccelerators


2/56

Chapter 1: Introduction 2


3/56


4/56


5/56

*ood)ro#e ational 'an4 $cenario 'ac4)round.................................................................. -6'usiness ssues..................................................................................................................... -6&echnical ssues.................................................................................................................... -7$ecurity ssues..................................................................................................................... . -7$olution +euirements.......................................................................................................... -;

esi)nin) the $olution.............................................................................................................. -<$olution (oncept................................................................................................................... -<$olution Prereuisites............................................................................................................80$olution rchitecture..............................................................................................................8%3o the $olution *or4s.................................................................................................... .... 82

dditional esi)n (onsiderations..........................................................................................8-Monitorin) and Mana)ement................................................................................................. 87

$ummary................................................................................................................................... 8<

Appendi$ A: #elated %in&s 51


6/56


7/56

to1factor reuirement si)nificantly reduces the li4elihood of unauthoriDed access to an

or)aniDation=s netor4.

$mart cards pro#ide particularly effecti#e security control in to scenarios: to secure

administrator accounts and to secure remote access. &his )uide concentrates on these

to scenarios as the priority areas in hich to implement smart cards.

'ecause administrator1le#el accounts ha#e a ide ran)e of user ri)hts, compromise ofone of these accounts can )i#e an intruder access to all netor4 resources. t is essential

to safe)uard administrator1le#el access because the theft of domain administrator1le#el

account credentials EeopardiDes the inte)rity of the domain, and possibly the entire forest,

to)ether ith any other trustin) forests. &o1factor authentication is essential for

administrator authentication.

/r)aniDations can pro#ide an important additional layer of security if they implement

smart cards for users ho reuire remote connecti#ity to netor4 resources. &o1factor

authentication is particularly important ith remote users, because it is not possible to

pro#ide any form of physical access control for remote connections. &o1factor

authentication ith smart cards can increase security on the authentication process for

remote users ho connect throu)h #irtual pri#ate netor4 BPC lin4s.

The *usiness Challenge(ompromise of administrator account credentials on domain1Eoined computers can

EeopardiDe the inte)rity of the entire domain, the forest in hich that domain resides, and

other forests and domains that ha#e trust relationships to that forest. &he compromise of

remote access accounts can result in the access of sensiti#e information throu)h dial1up

or P connections by e"ternal attac4ers.

&he business challen)e to safe)uard administrator and remote access connections is to

pro#ide a suitable le#el of security that does not compromise usability. n or)aniDation

that implements to1factor authentication to impro#e security cannot run at optimal

efficiency if users cannot access the information that they need to do their Eobs. t is of

critical importance to balance to1factor authentication a)ainst usability.

The *usiness *enefits

&he use of smart cards to secure critical accounts can produce the business benefits that

follo:

A +reater protection for sensiti(e data. $mart cards reduce the threat ofunauthoriDed access by the use of stolen credentials because the hac4er mustboth steal the smart card and obtain the P.

A *etter securit) for logon credentials. $mart cards use di)ital certificates forlo)on credentials, hich are difficult to for)e.

A !igher le(els of regulator) compliance. 'ein) able to identify that the lo))ed1onuser is ho they say they are pro#ides )reater credibility to monitored lo)s.

A %o,er probabilit) of repudiation. $mart card authentication reduces the ability of

indi#iduals to deny their actions.

A *etter integration ,ith access management s)stems. $ome smart cards alsofunction as 4ey cards to mana)e physical access, such as controlled door loc4s toaccess a physical site and beteen sectors ithin the site. &he combination ofsmart card and 4ey card ma4es it easy to control the e"act le#el of netor4 andphysical access for a user or an administrator, and reduces the fear of securitycompromise.


8/56


9/56

" The Secure Access sing Smart Cards lanning +uide

Chapter ": sing Smart Cards to !elp Secure #emote Access Accounts

&his chapter describes the desi)n considerations for remote access ith smart cards.

&he chapter )oes on to e"amine the issues and reuirements for the implementation of

secure remote access for *ood)ro#e 'an4. t discusses the solution concept,

prereuisites, solution architecture, and solution operation for the scenario. Finally, the

chapter re#ies ho to e"tend the solution to incorporate physical access control.


10/56

2Smart Card Technologiesetor4ed data stora)e is an essential business reuirement for nearly all or)aniDations.

/r)aniDations often ha#e to connect netor4s that contain sensiti#e and proprietary data

to the nternet for communication and to )enerate re#enue. &he constant dri#e for )reater

connecti#ity e"poses a si)nificant security ris4, because the maEority of or)aniDations use

user names and passords for authentication and to authoriDe access to netor4resources.

(hapter %, >ntroduction,> hi)hli)hted the main security issue ith user name and

passord combinations. 'ecause user names are not secret, only the passord pro#ides

any effecti#e security a)ainst an attac4er ho tries to impersonate a #alid user. &he

realiDation of the #ulnerability of user name and passord credentials has resulted in

increased interest in to1factor authentication systems.

T,oactor Authentication&o1factor authentication )oes beyond the simple user name and passord combination

and reuires a user to submit some form of uniue to4en to)ether ith a P. number

of ays e"ist to implement to1factor authentication, and doubtless more ill appear inthe future.

!ard,are To&ens

3ardare to4ens are a to1factor authentication method hereby users ha#e a physical

item such as a 4ey fob or a credit1card authenticator. &his hardare pro#ides a simple

one1time authentication code, hich typically chan)es e#ery 60 seconds. Users must

match the one1time code alon) ith a secret P to identify themsel#es uniuely and )ain

access.

3ardare to4ens pro#ide many of the benefits of smart cards, but can in#ol#e a more

comple" plan and deployment process. Microsoft? *indos $er#erG 200- and

*indos? IP do not pro#ide built1in support for hardare to4ens.

Smart Cards

$mart cards are credit card siDed plastic items that contain a microcomputer and a

small amount of memory, hich pro#ide secure, tamper1proof stora)e for pri#ate 4eys

and I.50< security certificates. $mart cards typically ha#e -2 or 68 H' of !lectrically

!rasable Pro)rammable +ead /nly Memory B!!P+/MC and +ead /nly Memory B+/MC,

ith Eust % H' of +M. &he +/M contains the smart card operatin) system, ith the

!!P+/M that contains the file and directory structures, P mana)ement applet, and


11/56

authentication certificate. &he +M pro#ides or4in) memory for card operations, such

as encryption and decryption.

&o authenticate to a computer or o#er a remote access connection, the user inserts the

smart card into a suitable reader and enters the P. &he user cannot )ain access ith

Eust the P, or ith Eust the smart card. 'rute force attac4s on smart card Ps are not

possible, because the smart card loc4s out after se#eral unsuccessful attempts to enter

the P. 'ecause Ps are usually ei)ht characters or less, they are easier to rememberthan lon) random character passords. $mart cards are the to1factor authentication

mechanism that Microsoft prefers.

ote: $mart card Ps do not ha#e to be numeric. $mart card #endor de#elopment 4itsenable you to specify ho many alphabetic, numeric, upper case, loer case, or non1alphanumeric characters you reuire.

Microsoft deploys smart cards for domain administrators and for remote access to

netor4 resources, and is 4een to promote this practice as part of the defense1in1depth

initiati#e. Microsoft (onsultin) $er#ices, Premier $upport, (ustomer $upport $er#ices,

Microsoft partners, and other solution pro#iders encoura)e or)aniDations to use smart

cards to secure netor4 access.&he folloin) list outlines the steps reuired to implement a smart card solution for

netor4 administrators:

A !nable the tar)et ser#ers to support interacti#e, secondary, and remote des4toplo)on ith smart card enabled accounts.

A dentify the administrators ho must use a smart card enabled domain1le#eladministrator account.

A eploy smart card readers.

A e#elop a secure process to distribute the smart cards and enroll theadministrators.

&he folloin) list outlines the process reuired to inte)rate a smart card solution for

remote access.

A Up)rade remote access ser#ers to support smart card authentication.

A dentify users ho must use smart cards for remote access.

A eploy smart card readers.

A istribute smart cards to the appropriate administrators and enroll the remoteusers.

Implementation rere/uisites$mart card deployment reuires a planned approach to ensure that or)aniDations

consider all the issues before the start of the implementation phase. &his section co#ers

the most common prereuisites, althou)h there mi)ht be additional reuirements in youren#ironment.

Identification of Accounts

&he identification of the users and the )roups that reuire smart card access is an

important part of a smart card deployment.


12/56

Chapter 2: Smart Card Technologies 4

ote: /r)aniDations that ha#e the bud)et and security reuirements to implementsmart card access for all users can s4ip this step.

roups and users that reuire smart cards mi)ht include:

A omain administrators for all domains in the forest

A $chema administrators

A !nterprise administrators

A atabase administrators

A 3uman resource administrators

A Users ho ha#e remote access

A Users ho ha#e either user or administrati#e access to sensiti#e resources, suchas accountin) and finance information

n or)aniDation mi)ht also reuire smart card access for users and )roups not in the

pre#ious list, such as board1le#el personnel. &he identification of these accounts early in

the process helps define the scope of the proEect and control costs.

&o identify critical accounts, you must define hen to use smart cards. For e"ample, )ood

security practice recommends that administrators ha#e to user accounts: a standard

account for daily tas4s such as e1mail, and an administrator1le#el account for ser#er

maintenance and other administrati#e tas4s. Usually, the administrator ould lo) on ith

the user1le#el account, and use the $econdary 9o)on ser#ice to perform administrati#e

tas4s. lternati#ely, the administrator can use the +emote es4top for dministration

component of *indos $er#er 200-, hich supports smart card lo)on. For more

information about administrator accounts, see the dentification of dministrator ccounts

and roups section in (hapter -, >Usin) $mart (ards to 3elp $ecure dministrator

ccounts.>

Smart Card Infrastructure Support

$mart cards reuire a suitable infrastructure ith support from the operatin) system andnetor4 elements. Microsoft pro#ides support for smart card implementations that use

the folloin) components:

A Microsoft (ertificate $er#ices or e"ternal Public Hey nfrastructure BPHC

A (ertificate templates

A *indos $er#er 200-

A &he cti#e irectory? directory ser#ice

A $ecurity roups

A roup Policy

A !nrollment $tations and !nrollment )ents

A cti#ation *eb $er#er

A !"tensible uthentication Protocol &ransport 9ayer $ecurity B!P &9$C Kreuired for remote access solutions only

dditional components include enrollment stations and enrollment a)ents.


13/56


14/56


supports secondary actions such as smart card lo)on o#er remote des4top protocol

B+PC connections. &his operatin) system reuirement includes the domain controllers.

For more information about this reuirement, see (hapter -, >Usin) $mart (ards to 3elp

$ecure dministrator ccounts.>

Acti(e irector)

cti#e irectory is a 4ey component for the implementation of smart card deployments. cti#e irectory in *indos $er#er 200- contains built1in support to enforce smart card

interacti#e lo)on and the ability to map accounts to certificates. &his capability to map

user accounts to certificates ties the pri#ate 4ey on the smart card to the certificate held

in cti#e irectory. &he presentation of smart card credentials at lo)on reuires cti#e

irectory to match that specific card to a uniue user account. For more information

about certificate mappin), see the Map (ertificates to User ccounts topic at

.microsoft.comresourcesdocumentation*indos$er#200-alldeploy)uideen1

usdsschp4icye4.asp.

cti#e irectory also supports security )roups and roup Policy to facilitate mana)ement

of the smart card lo)on process and smart card issuance.

Securit) +roups

&he smart card deployment and mana)ement process is si)nificantly easier if you use

security )roups ithin cti#e irectory to or)aniDe users. For e"ample, a typical smart

card deployment mi)ht reuire you to create the folloin) security )roups:

; Smart card enrollment agents. $mart card enrollment a)ents are responsible fordistribution of smart cards to users. &he ne"t section co#ers enrollment a)ents indetail.

; Smart card staging. &he smart card sta)in) )roup contains all users ho areauthoriDed to recei#e smart cards, but for hom an enrollment a)ent has not yetenrolled and acti#ated their cards.

; Smart card users. &his )roup contains all users ho ha#e completed theenrollment process and ha#e an acti#ated smart card. &he enrollment a)ent mo#es

the user from the smart card sta)in) )roup to the smart card users )roup.

For more information about ho to create )roups, see the (hec4list: (reatin) a roup

topic at

.microsoft.comresourcesdocumentation*indos$er#200-standardproddocsen1

ussa)ad)roupschec4listcreate)roup.asp.

+roup olic)

roup Policy enables you to apply confi)uration settin)s to multiple computers. Lou can

set up the reuirement to use smart cards for interacti#e lo)on in a roup Policy obEect

BP/C and then apply that P/ to or)aniDational units or sites in cti#e irectory. For

more information about ho to use roup Policy, see (hapter -, >Usin) $mart (ards to

3elp $ecure dministrator ccounts.>

'nrollment Stations and 'nrollment Agents

n or)aniDation can use a *eb1based interface to issue or enroll users for smart cards,

hereby users enter their credentials and obtain their smart card. 3oe#er, this

arran)ement effecti#ely don)rades the security for the smart card to the same le#el as

the credentials presented to the *eb interface. &he preferred solution is to create

enrollment stations and desi)nate one or more administrators as enrollment a)ents.

http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssch_pki_cyek.asphttp://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssch_pki_cyek.asphttp://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_adgroups_checklist_create_group.asphttp://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssch_pki_cyek.asphttp://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_adgroups_checklist_create_group.asp


15/56


16/56


(ertificates that ha#e lon)er 4ey len)ths pro#ide )reater security than shorter 4ey

len)ths, but lon)er 4ey len)ths si)nificantly increase the time to lo) on ith a smart card.

Memory limitations in the smart card also restrict the ma"imum 4ey len)th you can use.

(ertificate 4ey len)ths of %,028 bits are suitable to secure administrator accounts or to

secure remote access. certificate ith a %,0281bit 4ey ta4es appro"imately 2.5 H' of

memory space in the smart card. /ther memory reuirements include the operatin)

system B%6 H'C, smart card #endor applications such as the ($P B; H'C, and the smartcard file and directory structure B8 H'C. 3ence, smart cards that ha#e less than -2 H' of

memory are unli4ely to be suitable for the stora)e of lo)on certificates and pro#ide the

reuired functionality to e"tend a smart card solution.

&he second factor to consider is hether the card has built1in support for *indos

$er#er 200- and *indos IP. 'efore you purchase smart cards, discuss your

reuirements ith the #endor.

ote: Lou should obtain smart cards directly from their respecti#e #endors. $martcards are not a#ailable from Microsoft.

lthou)h *indos IP and the *indos $er#er 200- family include built1in support for

some smart cards, additional +$1based crypto)raphic smart cards also function ellith those operatin) systems. For those cards hose support is not included nati#ely

ithin *indos, the card #endor must implement a ($P for the card that uses the

(ryptoP.

For more information about the e#aluation of smart cards, see the !#aluatin) $mart

(ards and +eaders topic at

.microsoft.comtechnetprodtechnolindosser#er200-libraryepHit0eae-;ec1

d6e518ca71


17/56

12 The 6icrosoft Secure Access using Smart Cards lanning +uide

Smart Card Soft,are e(elopment 7its

Microsoft does not pro#ide an off1the1shelf solution for smart card deployment. Lou mi)ht

ha#e to pro#ide additional customiDation if your en#ironment reuires it.

$mart card #endors offer $Hs and personaliDation tools that enable or)aniDations to

customiDe their smart card deployments. For e"ample, de#elopers can use an $H to

issue smart cards in a pendin) state. *hen the enrollment a)ent issues the card, theuser acti#ates the card and chan)es the P. f you ant to ta4e ad#anta)e of the )reater

security this method pro#ides, you must bud)et for additional customiDation and

de#elopment.

'(aluating Smart Card #eaders

&he principal factor hen you select a suitable smart card reader is to choose one that is

best suited to its purpose. For e"ample, a modern or4station that sits underneath an

administratorNs des4 has to or more U$' connections, so a U$' smart card reader is

probably the most appropriate choice. &he user can attach the smart card reader to the

side of his monitor or place the reader in another con#enient location. Users that ma4e

remote access connections from laptops usually prefer a smart card reader in the P(

card format.Heyboards can include smart card readers that also or4 throu)h a U$' interface. &hese

4eyboards are suitable for use ith a sin)le computer, and mi)ht or4 ith multiple

computers in ser#er rac4s throu)h U$'1euipped Heyboard ideo Mouse BHMC

sitches. (hec4 ith your chosen HM sitch manufacturer to see hether their HM

sitches support smart card authentication to multiple ser#ers.

*indos IP and the *indos $er#er 200- family support the smart card readers listed

in the folloin) table. *indos installs the correct dri#ers upon detection of the Plu) and

Play smart card reader hardare.

ote: Microsoft stron)ly recommends that you use smart card readers that ha#eobtained the *indos1compatible lo)o.

Table 2.1: Smart Card #eaders Supported in -indo,s Ser(er 2883

*rand 6odel Interface

merican !"press (+8-5 U$'

'ull $mar&9P- $erial

(ompa $erial reader $erial

emplus (+8%0P $erial

emplus P+800 P(M(

emplus emP(8-0 U$'

3elett Pac4ard Protect&ools $erial

9itronic 220P $erial

$chlumber)er +efle" 20 P(M(

$chlumber)er +efle" 72 $erial

$chlumber)er +efle" 9ite $erial

$(onnection Mana)er

Microsystems$(+%%% $erial

$(onnection Mana)er $(+200 $erial


18/56


*rand 6odel Interface

Microsystems

$(onnection Mana)er

Microsystems$(+%20 P(M(

$(onnection Mana)er

Microsystems

$(+-00 U$'

$ystemneeds !"ternal $erial

/mni4ey 20%0 $erial

/mni4ey 2020 U$'

/mni4ey 8000 P(M(%.

ote: $mart card readers that use a serial interface reuire a computer restart afterinstallation. &his reuirement mi)ht not be acceptable for ser#er implementations.

Microsoft neither supports nor recommends the use of smart card readers that are not

Plu) and Play. f you use such a reader, you must obtain installation instructions Bthis

includes associated de#ice dri#er softareC directly from the manufacturer of the smartcard reader.

The -oodgro(e ational *an& Scenario&he chapters that remain of this )uide use the *ood)ro#e ational 'an4 scenario.

*ood)ro#e ational 'an4 is a fictional )lobal in#estment ban4 that ser#es institutional,

corporate, )o#ernment, and indi#idual clients in its role as a financial intermediary. ts

business includes securities, sales and tradin), financial ad#isory ser#ices, in#estment

research, #enture capital, and bro4era)e ser#ices for financial institutions.

*ood)ro#e ational 'an4 employs more than %5,000 people in more than 60 offices

orldide. &hey ha#e corporate headuarters Bhub locationsC that ha#e lar)e numbers of

employees in e Lor4 B5,000 employeesC, 9ondon B5,200 employeesC, and &o4yo B500employeesC. !ach hub location supports se#eral offices.

lthou)h *ood)ro#e ational 'an4 has a mi"ed ser#er en#ironment ith *indos

$er#er and UI, their infrastructure runs on a *indos $er#er bac4bone. &hey ha#e

%,7%2 *indos ser#ers, most of hich run *indos $er#er 200-. bout %00 of these

ser#ers are nternet1facin). &here are also %;,000 or4stations ithin the or)aniDation,

and 2,000 laptops. &he or)aniDation is in the process of settin) a baseline that

standardiDes on *indos IP Professional ith $P2 and a ser#er standard of *indos

$er#er 200- ith $P%.

&he maEority of ser#ers are located in three corporate headuarters locations. &he

or)aniDation has distributed the or4stations and laptops throu)hout all locations. &he

laptops often mo#e beteen countries or re)ions. *ood)ro#e ational 'an4 uses

Microsoft $ystems Mana)ement $er#er 200- to mana)e des4top and laptop computersand Microsoft /perations Mana)er BM/MC 2005 to mana)e ser#ers.

*ood)ro#e ational 'an4 must operate ithin the reuirements of the rele#ant financial

re)ulatory frameor4s for each countryre)ion in hich it operates. t must also comply

ith all applicable data protection le)islation and demonstrate effecti#e operational

security.

&he remainder of this document describes the desi)n choices a#ailable to *ood)ro#e

ational 'an4 as they planned their smart card deployment.


19/56


20/56

3Using Smart Cards to HelpSecure AdministratorAccounts

Microsoft? *indos $er#erG 200- enables or)aniDations to help secure administrati#e

accounts throu)h a set of specific account security features. n addition to the

reuirement that administrators lo) on ith smart cards, *indos $er#er 200- supports

smart card authentication ith the listed secondary actions:

A (reate a mapped dri#e ith the net use command.

A Use the $econdary 9o)on ser#ice by typin) runas at the command prompt.

A nstall the cti#e irectory? directory ser#ice by usin) the cti#e irectorynstallation *iDard Bhich you can access if you type dcpromo at the commandpromptC.

A 9o) on throu)h *indos $er#er 200- +emote es4top sessions

A 9o) on throu)h *indos $er#er 200- &erminal $er#er sessions

ote: lthou)h Microsoft *indos? 2000 supports smart card access forauthentication, it does not support these additional features, hich are a#ailable in*indos $er#er 200- only.

Approaches to Securing Administrator Accounts,ith Smart Cards

*indos $er#er 200- support for smart card authentication of secondary actions enables

better se)re)ation of user and administrator accounts. For e#eryday actions,administrators can lo) on to or4stations ith non1administrati#e accounts. f they must

perform an administrati#e tas4, administrators can use their smart cards to authenticate

the action by use of a secondary action. &his is a more secure and con#enient

arran)ement than if the administrator is reuired to enter a user name and a passord or

reuired to lo) off and lo) on a)ain ith an administrator account.


21/56


22/56


23/56


*ith the user account smart card reuirement selected, the administrator must use a

smart card to lo) on interacti#ely to any computer in the domain, not Eust the protected

ser#ers. &his could be incon#enient if not all computers ha#e smart card readers.

f you enforce smart card use throu)h the user account properties, administrators cannot

remotely administer computers that run *indos 2000 $er#er. *indos 2000 $er#er

&erminal $er#ices sessions donNt support smart card redirection, so the administrator

must lo) on locally to mana)e any computers that run *indos 2000. &his reuirementcould be #ery incon#enient if the administrator is at a different location from the ser#er.

+roup olic)

more mana)eable approach is to use roup Policy settin)s to specify that certain

computers reuire smart cards for interacti#e lo)on, and to control hat happens hen a

user remo#es a smart card. Lou can create roup Policy obEects BP/sC ith these

settin)s confi)ured and lin4 the P/s to the or)aniDational unit B/UC that contains the

computer for hich you reuire smart card lo)on. &he path to the smart cards options in

roup Policy is (omputer (onfi)urationQ*indos $ettin)sQ$ecurity $ettin)sQ9ocal

PoliciesQ$ecurity /ptions. &he settin)s are Interacti(e logon: #e/uire smart card and

Interacti(e %ogon: Smart card remo(al beha(ior .

ote: &his settin) reuires either *indos IP ith $er#ice Pac4 2 or an update forthis settin). For more information, see the Update for the >interacti#e lo)on: reuiresmart card> security settin) in *indos IP Hnoled)e 'ase article athttp:support.microsoft.comOid;-8;75.

For )reatest security, you should reuire smart cards for interacti#e lo)on and then set

the smart card remo#al policy to loc4 the or4station or lo) off the user. &hese roup

Policy settin)s should become part of a customiDed P/ that applies to administrators.

P/s can apply to the site, domain, or /U le#el. n most cases, P/s that apply smart

card settin)s apply to an /U.

ote: Microsoft recommends that you not modify the efault omain (ontrollers Policy

or the efault omain Policy to include smart card settin)s or any other policychan)es. lays create a ne P/ or use a P/ that e"ists to set roup Policysettin)s for smart card lo)on.

&he roup Policy settin)s for smart cards control interacti#e lo)on and do not affect

access to a ser#er across the netor4. nteracti#e lo)on includes lo))in) on ith +emote

es4top or &erminal $er#ices.

Microsoft recommends that you implement smart cards for administrators ith other

control mechanisms such as Psec or roup Policy settin)s to pre#ent the mana)ement

of a ser#er ith remote administration tools such as Microsoft Mana)ement (onsole

BMM(C tools.

6anaging Smart Card Access in 6ultiple omains andorests

&he implementation of smart cards for administrators reuires that you understand the

issues in#ol#ed ith multiple domains and forests. For e"ample, administrators ho are

members of the omain dmins )roup in more than one forest mi)ht need one smart

card for each forest in hich they ha#e administrati#e ri)hts. &his reuirement can result

in these administrators ha#in) to carry se#eral smart cards.

http://support.microsoft.com/?id=834875http://support.microsoft.com/?id=834875http://support.microsoft.com/?id=834875http://support.microsoft.com/?id=834875http://support.microsoft.com/?id=834875


24/56

Chapter 3: sing Smart Cards to !elp Secure Administrator Accounts 19

lthou)h smart cards can contain more than one certificate, *indos $er#er 200-

currently can only accept one smart card lo)on certificate Bthe certificate held in slot 0 on

the smart cardC for each certification authority B(C certificate root. &his constraint mi)ht

reuire some netor4 administrators to carry multiple smart cards unless the or)aniDation

has trust relationships beteen forests.

Securing Ser(ers(omputers that run ser#ices, such as file and print, databases, e1mail, and directories,

reuire hi)her le#els of security than or4stations. n particular, you should consider the

use of smart card authentication for all accounts that administer computers that ha#e the

folloin) roles:

A omain controllers

A atabase ser#ers

A (ertificate ser#ers

A File and print ser#ers

Securing omain Controllers

omain controllers are the most important computers for the use of to1factor

authentication, because these computers contain and control all of the domain account

information and apply security rules to each account. f an attac4er compromises a

domain controller, the attac4er could then create a ne account, escalate pri#ile)es, or

access all domain controllers as an administrator.

Securing atabase Ser(ers

database ser#er stores information that is critical to the operation of an or)aniDation.

&his stored information mi)ht be subEect to strict chec41in and chec41out processes, ith

audit trac4in) of data access reuests. !"amples of database ser#ers include ser#ers

that store the source code for a softare company, the secret recipes of a be#era)e

manufacturer, or customer account information. $mart card authentication should secure

access to all database ser#ers.

n or)aniDation should identify hi)h security ser#ers, and or4 ith their oners to

chan)e the type of account on hich the ser#ice or scheduled tas4 runs, or place the

accounts and ser#ers into special security )roups that ha#e )reater access and user

restrictions.

Securing Certificate Ser(ers

&he ser#ers that host certification authorities and (ertificate $er#ices must ha#e a hi)h

le#el of security. &he compromise of the certification authority #oids the inte)rity of the

or)aniDation, renderin) all issued certificates as insecure. $er#ers that host (ertificate

$er#ices must ha#e the hi)hest security priority both from the netor4 and for physical

access.

Securing ile and rint Ser(ers

file ser#er can host important company documents and confidential information. &he

compromise of this information could harm future re#enues or incur penalties from

re)ulatory or)aniDations. $mart card authentication must definitely secure print ser#ers

that print in#oices or ban4 chec4s.

For more information about the security features in *indos $er#er 200-, see the

*indos $er#er 200- $ecurity uide at http:)o.microsoft.comflin4Olin4id%8;85.

http://go.microsoft.com/fwlink/?linkid=14845http://go.microsoft.com/fwlink/?linkid=14845


25/56


26/56


&he administrator then uses the P reset tool to reset the default P or uses the P

unbloc4 tool in conEunction ith the cti#ation *eb ser#er to set a ne P. &he

administratorNs smart card is no ready for use.

6anaging Smart Cards

&he implementation of smart cards is not a one1time action, because the security

certificates embedded on the cards reuire mana)ement and you must cope ithsituations in hich administrators for)et their smart cards, lose them, or ha#e them

stolen. Lou should establish applicable procedures and an appropriate bud)et for smart

card mana)ement.

'$ceptions 6anagement

Lour or)aniDation needs to de#elop a plan that focuses on ho to mana)e situations in

hich administrator smart cards are for)otten, lost, or stolen. 3o your or)aniDation

implements the plan depends on ho smart card lo)on reuirements are enforced in your

or)aniDation.

f your or)aniDation has chosen to enforce a smart card lo)on reuirement throu)h user

accounts in cti#e irectory, you can easily )rant an e"ception to the affected user in

such a situation. &he method for )rantin) the e"ception ould be to remo#e the

reuirement for smart card lo)on for the account, and then reset the passord after

ensurin) that the ser must change pass,ord at ne$t logon settin) is enabled. Lou

could then pro#ide the passord to the account oner, and after a reasonable period, re1

enable the reuirement. &o apply this method, in cti#e irectory Users and (omputers,

double1clic4 the user name, clic4 the Account tab, and then under Account 0ptions,

clear the chec4 bo" for Smart card is re/uired for interacti(e logon and select the

chec4 bo" for ser must change pass,ord at ne$t logon. (lic4 07, and then from the

conte"t menu, ri)ht1clic4 the user name and select #eset ass,ord to set the passord

and enforce these reuirements for the administrator.

f your or)aniDation uses roup Policy to enforce the smart card lo)on reuirement, there

is no ay to create an e"ception for a user at this time. n this case, you ill ha#e to

determine a policy appropriate for your or)aniDation that administrators can follo in thee#ent that they for)et or lose their smart cards.

n the case of for)otten smart cards, you can implement a number of responses. For

e"ample, a policy mi)ht reuire administrators to return home to retrie#e misplaced smart

cards.

f your or)aniDation outsources its smart card infrastructure, you could implement a policy

that reuires an administrator to maintain a fe )eneric smart cards ith certificates tied

to specific user accounts on site. f a user loses a smart card, an administrator could

temporarily issue one of these )eneric smart cards to the user ith the understandin)

that the user is responsible for any actions ta4en to access resources ith the )eneric

account. n such a policy, it is recommended that the administrator ho maintains the

)eneric smart cards reset the passord P on the smart card each time prior to issuin)

it to a user.

f your or)aniDation maintains its on smart card infrastructure, you could issue a ne

certificate ith a short lifespan to a )eneric user account. Under this e"ceptions

mana)ement method, the administrator ould a)ain be accountable for usin) the )eneric

account to access resources.

Finally, hen an administrator loses a smart card, your or)aniDation should institute a

policy to issue a ne smart card to the administrator, and re#o4e the administratorNs old

certificate.


27/56


Certificate #e(ocation

Lou mi)ht ha#e to re#o4e a certificate under a number of circumstances, for e"ample, on

compromise of the pri#ate 4ey, if the smart card user chan)es assi)nments, or hen the

user lea#es the or)aniDation. *hen you re#o4e a certificate, this action publishes details

about the certificate to the certificate re#ocation list B(+9C location. &his location is

typically a U+9 or a netor4 U( path.

n issued certificate includes a list of distribution points here an authentication ser#er

can #erify the status of the certificate a)ainst the (+9. For more information about

certificate re#ocation, see the +e#o4in) certificates and publishin) (+9s topic at

.microsoft.comresourcesdocumentation*indos$er#200-standardproddocsen1

ussa)($$r#d(+9.asp.

Certificate #ene,al

&he e"piration date of the di)ital certificate on a smart card depends on the settin)s in

the certificate template that creates the smart card certificate. (ertificates for smart card

use ha#e typical lifetimes from si" months to to years.

*hen a certificate comes toards the end of its lifetime, it reuires reneal to ensure that

the oner can continue to use the certificate or replace it. n certificate reneal, thereneal reuester already ons a certificate. &he reneal ta4es the information of the

current certificate into account hen the reneal reuest is submitted. Lou can then

rene a certificate ith a ne 4ey or use the current 4ey.

Certificate Autoenrollment

(ertificate autoenrollment is feature of *indos $er#er 200-, !nterprise !dition

(ertificate $er#ices that automatically si)ns a reneal reuest usin) the e"istin)

certificate to obtain a ne certificate. &his feature helps in the mana)ement of lar)e

numbers of certificates. For more information about certificate autoenrollment, see

(ertificate utoenrollment in *indos $er#er 200-, at http:)o.microsoft.comflin4O

lin4id6


28/56


*ac&ground

*ood)ro#e ational 'an4 possesses a number of critical ser#ers that reuire ti)ht

administrati#e control and secure access. dministrators currently authenticate to these

critical ser#ers by usin) a user name and passord combination. UnauthoriDed users

ha#e attempted to access critical ser#ers ith stolen credentials.

*usiness Issues

*ood)ro#e ational 'an4 has identified the folloin) three business continuity and

administrator accountability issues:

; Accountabilit). &he & department cannot #erify critical chan)es to ser#ers byadministrators ho use user name and passord authentication becauseadministrators often share credentials.

; rotection of credentials. Malicious or ro)ue users ho steal administratorsNcredentials can seriously affect the reputation of the or)aniDation and )eneratefinancial costs throu)h dontime. $mart card authentication ould si)nificantlyreduce the possibility of theft of administrator credentials.

; *usiness continuit). 'ecause *ood)ro#e ational 'an4 cannot allo chan)es

to netor4 confi)uration to disrupt business ser#ices, a carefully planned approachis essential durin) the implementation phase of the smart card solution.

Technical Issues

&he *ood)ro#e ational 'an4 & department has identified the folloin) technical issues

that must be o#ercome to implement a smart card solution:

; Support for smart card readers. !#ery ser#er that administrators need to accessith a smart card must pro#ide hardare support for a smart card reader.

; Implement operational best practices. &he inte)rity of a smart card deploymentis dependent upon effecti#e lon)1term mana)ement and maintenance. *ood)ro#eational 'an4 & should implement the operational best practices outlined by theMicrosoft /perations Frameor4 BM/FC.

; Scheduled tas&s that run ,ith administrator rights on a smart cardrestrictedser(er . *ood)ro#e ational 'an4 runs scheduled tas4s that use accounts ithadministrator1le#el pri#ile)es. *ood)ro#e ational 'an4 needs to re#ie theseaccounts and, here possible, use accounts that do not reuire administrati#epri#ile)es. *ood)ro#e ational 'an4 must also implement a permanent e"clusion)roup that includes any accounts that run scheduled tas4s so that these accountsare e"empt from the reuirement for smart card lo)on.

; Integration ,ith I>. *ood)ro#e ational 'an4 operates a hetero)eneousen#ironment, so smart card inte)ration ith computers that run UI is a concern.*ood)ro#e ational 'an4 plans to in#esti)ate products such as &rust'ro4er from(yber$afe 9imited that pro#ide inte)rated smart card authentication for both*indos and UI.

Securit) Issues

&he )oal of usin) smart cards to help secure administrator accounts is to impro#e

security and accountability. &he *ood)ro#e ational 'an4 & department has identified

the folloin) security issues that the ban4 must address before they can deploy the

solution:

; istribution and acti(ation. &he distribution and acti#ation of the smart cards isimportant to maintain the inte)rity of the entire solution. 'ecause *ood)ro#e


29/56

2" The 6icrosoft Secure Access using Smart Cards lanning +uide

ational 'an4 has sites throu)hout the orld, *ood)ro#e & cannot distributesmart cards from a sin)le source location. erification of smart card recipients is a4ey factor to maintain the inte)rity of the proEect. *ood)ro#e ational 'an4 plansto deploy security teams that use 3uman +esources identification data to ensurethat they issue each smart card to the correct person.

; %eastpri(ilege approach to administrati(e rights. *ood)ro#e ational 'an4

should e"amine its current netor4 administration model and reduce the number of user and ser#ice accounts that run ith full administrati#e pri#ile)es. &he ban4should assi)n only those pri#ile)es that administrators reuire to do their Eobs. &heanalysis and reduction in the number of administrator accounts can help in thedeployment, monitorin), and continued mana)ement of the smart card solution.

; 6anagement of ser(ice accounts. *ood)ro#e & re#ieed pro)ram ser#iceaccounts and has ensured that as fe ser#ices as possible reuire administratorsecurity conte"t. Many pro)rams are mar4ed for either up)rades or replacement.

; 0ne smart card for each forest in a full trust relationship. *ood)ro#e ational'an4 has to forests lin4ed by a to1ay trust relationship. lthou)h a smart cardcan hold multiple certificates, *indos $er#er 200- only uses the certificatelocated in slot 0 of the smart card for interacti#e lo)on. &his desi)n reuiresnetor4 administrators ho or4 across multiple unlin4ed forests to ha#e multiple

smart cards. 3oe#er, an administrator ith a smart card has access to resourcesin all forests ith hich the forest that authenticates the administrator has a fulltrust relationship, unless a security restriction in the trustin) forest o#errides thisaccess.

; I management. &he security and inte)rity of the smart card solution increases if users can easily chan)e their Ps. 3ence, *ood)ro#e ational 'an4 &department acuired suitable P mana)ement tools from the selected smart card#endor.

Solution #e/uirements

fter the re#ie of the initial pilot, *ood)ro#e & de#eloped specific solution

reuirements. &he solution employed by *ood)ro#e ational 'an4 to help secure

administrator accounts that ha#e smart cards must:

A !nsure that secured ser#ers reuire a #alid smart card for an interacti#e,secondary, or +emote es4top lo)on.

A istribute and acti#ate smart cards in a secure and timely manner.

A Pro#ide an audit of the access to secure ser#ers, and collect the resultant securitydata in a central repository.

A !nable mana)ement and monitorin) of smart card use.

A !nsure rapid re#ocation of compromised certificates, such as on lost or stolensmart cards.

A Pro#ide a structure for on)oin) mana)ement.

*ood)ro#e ational 'an4 has identified se#eral 4ey business, technical, and securityissues that emer)ed from the initial plan. *ood)ro#e & performed a re#ie to address

these issues and conducted tests of or4arounds and fi"es. *ood)ro#e ational 'an4

has created detailed plans for the deployment phase of the solution.

esigning the Solution fter you understand the business, technical, and security issues that the smart card

solution must address, you can desi)n a solution that suits your en#ironment. &he desi)n


30/56


process identifies the essential elements and lo)ically analyDes the reuirements to plan

the solution.

*ood)ro#e ational 'an4 has carried out this appraisal. &his section describes the

issues from the initial plan that *ood)ro#e ational 'an4 system architects considered,

the conclusions they reached, and the desi)n decisions that they made.

&his section outlines the desi)n choices made by *ood)ro#e ational 'an4 & to helpsecure administrator accounts by the use of smart cards. t details the solution concept

and its prereuisites and describes the architecture that *ood)ro#e ational 'an4

planned.

Solution Concept

n the proposed solution, all ser#er administration acti#ity reuires authentication of the

administratorNs identity by the presentation of a certificate stored on a smart card and its

correspondin) P. &he solution uses a combination of roup Policy settin)s, I.50<

#ersion - B#-C user certificates, smart cards, and smart card readers. &he solution

reuires the installation of an I.50< #- certificate onto the smart card.

&o lo) on to a ser#er, the administrator inserts the smart card into a smart card reader

installed on the computer. &he insertion of the card causes the operatin) system todisplay a prompt for the P. &he administrator then enters the P for the smart card. f

the P is correct, the administrator can access the ser#er ith administrati#e ri)hts.

Solution rere/uisites

*hen you en)a)e in a proEect of this nature, it is necessary to meet a number of

prereuisites. &hese prereuisites include the recruitment of the proEect team,

consultation ith the user base, the implementation of tests or pilots, and the need to

up)rade the hardare and softare to meet the solution reuirements.

Consulting Administrati(e Teams

4ey consideration hen a chan)in) a user ser#ice is to consult the users and )roups

in#ol#ed. n return, the users must understand hat they can e"pect and not e"pect fromthe ser#ice. Mutual consultation and the mana)ement of user e"pectations is often the

4ey to user acceptance. Measurable obEecti#es must be set to Eud)e the ultimate success

of the proEect in a rational manner. &hese obEecti#es mi)ht include the reduction of

security1related incidents associated ith stolen credentials.

*ood)ro#e ational 'an4 operates in se#eral countriesre)ions throu)hout the orld,

and uses re)ional support centers. &he initial desi)n team e"tensi#ely can#assed

administrati#e teams in all locations to identify candidate ser#ers for the smart card

solution. &he team also identified any ser#ers that they ould not be able to up)rade to

meet the solution prereuisites ithin an acceptable timescale.

#ecruitment of the ro?ect Team

!nsure that you ha#e the ri)ht personnel and s4ills to implement a proEect of this nature.&he proEect team is li4ely to reuire input from the folloin) representati#e occupations:

A Pro)ram mana)er

A nformation systems architect

A $ystems analyst or inte)rator

A $ystems en)ineers

A Product release mana)er


31/56

2@ The 6icrosoft Secure Access using Smart Cards lanning +uide

A Product testin) mana)er

A $upport or help des4 mana)er

A User support specialists

A $ecurity officers

For more information about representati#e occupations and M/F role associations, see

&he Microsoft $olutions Frameor4 $upplemental *hitepapers & /ccupation

&a"onomy at .microsoft.comdonloadsdetails.asp"OFamily;-


32/56


Smart Cards Acti(ation

'ecause administrators recei#ed their smart cards in a pendin) state, the cards reuire

acti#ation prior to use. &he administrator acti#ates his smart card hen he inserts the

card into a smart card reader, enters a challen)e, and then chan)es the P.

Smart Cards 6anagement and Support

lthou)h the administrators at *ood)ro#e ational 'an4 are a technically astute )roup,

the smart card deployment team needed to or4 closely ith help des4. 3elp des4

personnel reuired suitable instruction so that they could handle any ueries that arose.

'$ception 6anagement

*ood)ro#e ational 'an4 instituted a corporate policy to cope ith lost, stolen, or

for)otten cards. For lost or stolen cards, the & department re#o4es all assi)ned

certificates and issues ne cards ithin 28 hours. &he & department deals ith

administrators ho for)et to brin) their smart cards to or4 by issuin) them temporary

smart cards. lthou)h a certificate mi)ht be re#o4ed, it does not mean the smart card is

deacti#ated durin) that same time. *ood)ro#e must re#ie the (+9 policies to match the

security policies.

Certificate #e(ocation

&he smart card lo)on certificates for *ood)ro#e ational 'an4 administrators use

intranet U+9s to locate the (+9 and chec4 for re#o4ed certificates. &he & department

implemented *indos etor4 9oad 'alancin) B9'C to ensure hi)h a#ailability for the

*eb site that hosts the (+9.

Certificate #ene,al

&he *ood)ro#e ational 'an4 & department de#eloped a certificate reneal process

that reuires the administratorNs mana)er to appro#e the smart card reneal reuest.

fter the mana)er appro#es a reuest, the current certificate si)ns the certificate reuest

and the smart card certificate is reneed.

6onitoring the Solution*ood)ro#e ational 'an4 uses Microsoft /perations Mana)er BM/MC 2005 to collect

and analyDe security e#ent lo)s and to monitor the solution a#ailability and performance.

&he smart card solution inte)rates ith M/M, monitors security e#ent lo)s, and pro#ides

alerts and produces usa)e reports. *ood)ro#e ational 'an4 plans to re#ie the ser#ice

on a uarterly basis and to )enerate reports from the M/M data.


33/56


34/56


&he folloin) fi)ure illustrates this process.

igure 3.1Smart card logon authentication process

*ood)ro#e ational 'an4 & lin4ed a P/ to the or)aniDational units that contain the

ser#ers that reuire smart card authentication. &his P/ applies the chan)es to the

folloin) computer confi)uration settin)s:

A nteracti#e lo)on reuires a smart card

A +emo#al of the smart card forces the account to lo) off

&hese settin)s help pre#ent administrators from sharin) smart cards or lea#in) a ser#er

unattended hile lo))ed on.

'$tending the Solution*ood)ro#e ational 'an4 en#isions inte)ration of the smart card solution into the ser#er

and application chan)e mana)ement process. &he plan is to authenticate each sta)e of

the chan)e mana)ement process, and inte)rate this process into the or4flo. For

e"ample, chan)es to the *ood)ro#e *eb ser#er ould reuire #erification from to or

more *eb administrators.

Summar)Usin) smart cards to authenticate administrator user accounts reduces fraudulent access

to critical computers and increases the inte)rity and accountability of ser#er

administration. &he implementation of smart cards for administrators ill benefit your

or)aniDation by the reduction of security incidents and the increased uality ofadministrati#e procedures.


35/56

4Using Smart Cards to HelpSecure Remote AccessAccounts

Most or)aniDations must pro#ide remote access to netor4 resources o#er dial1up or

#irtual pri#ate netor4 BPC connections. /n)oin) chan)es to business practices, such

as the pro#ision of support for remote users or field sales staff, ill only accelerate this

trend. lthou)h remote access pro#ides numerous ad#anta)es to an or)aniDation, any

e"ternal access si)nificantly e"poses the or)aniDationNs netor4 to potential security

threats. &o1factor authentication is an increased reuirement for netor4s that support

remote access.

Securing #emote Access ,ith Smart Cards+emote access should enable all authoriDed employees to access an or)aniDationNs

intranet resources. &o facilitate remote access throu)h P, you must open up ports on

your e"ternal firealls. &his increase in accessibility creates a route throu)h hich

attac4ers can possibly penetrate the netor4.

(hapter %, >ntroduction,> of this )uide points out that the authentication of accounts that

rely on user names and passords concentrates all the access control security on the

passord. Passords are #ulnerable to compromise, and the credentials for a

compromised account that has remote access to a corporate netor4 could be of interest

to criminal or)aniDations.

lthou)h you can confi)ure a domain passord loc4out policy for user accounts, the

account loc4out policy pro#ides an opportunity for denial of ser#ice Bo$C attac4s by

constantly loc4in) out the remote user account. lthou)h this attac4 does not

compromise any information on the netor4, it is a source of frustration for the loc4ed out

user.

$tron) user authentication that uses di)ital certificates embedded in a smart card

pro#ides a robust and fle"ible approach to secure remote access connections.

Client #e/uirements

&he use of smart cards to control remote access depends on the components that run on

the remote client. Lou must ha#e a )ood le#el of 4noled)e of these components, and in

particular, (onnection Mana)er and the (onnection Mana)er dministration Hit B(MHC.


36/56

(onnection Mana)er centraliDes and automates the establishment and mana)ement of

netor4 connections. (onnection Mana)er supports the folloin) 4ey areas for the

confi)uration of smart card access:

A !"tensible uthentication Protocol &ransport 9ayer $ecurity B!P1&9$C for Pand remote access connections

A pplication1le#el security chec4s to mana)e client computer confi)urationsautomatically

A (omputer security chec4s and #alidations that are part of the lo)on process

For more information about (onnection Mana)er and (MH, see (onnection Mana)er

dministration Hit at

.microsoft.comtechnetprodtechnolindosser#er200-library$er#er3elpbe5c%c-

71%0


37/56

Chapter ": sing Smart Cards to !elp Secure #emote Access Accounts 33

Ser(er #e/uirements

$er#er reuirements for smart card access are relati#ely strai)htforard. &he remote

access ser#ers must run *indos 2000 $er#er or later and must support !P1&9$.

ote: Unli4e the smart cards for the administrators scenario, the smart cards for theremote access scenario do not reuire Microsoft *indos $er#erG 200-, althou)h it ishi)hly recommended that you up)rade your PH to *indos $er#er 200- ith $er#icePac4 % B$P%C or later.

ialup and V Considerations

&he solution uses smart cards to secure remote access supports dial1up access throu)h

nte)rated $er#ices i)ital etor4 B$C or Public $itched &elephone etor4

BP$&C connections, but users mi)ht e"perience e"tended lo)on times.

+emote connections that use P connections place an additional processor load on the

remote access ser#er. $mart card secured lo)on does not add noticeably to that load but

can increase lo)on times. P remote access ser#ers that ser#ice a hi)h #olume of

inbound connections reuire fast processors, preferably in a multiprocessor confi)uration.

/r)aniDations that use Psec secured Ps can implement netor4 cards that offloadthe Psec encryption process onto a separate processor on the netor4 card.

Support for '$tensible Authentication rotocol

!P1&9$ is a mutual authentication mechanism de#eloped for use ith authentication

methods in conEunction ith security de#ices, such as smart cards and hardare to4ens.

!P1&9$ supports Point1to1Point Protocol BPPPC and P connections, and enables

e"chan)e of shared secret 4eys for Microsoft Point1to1Point !ncryption BMPP!C.

&he main benefits of !P1&9$ are its resistance to brute force attac4s and its support for

mutual authentication. *ith mutual authentication, both client and ser#er must pro#e their

identities to the other. f either client or ser#er does not send a certificate to #alidate its

identity, the connection terminates.

*indos $er#er 200- supports !P1&9$ for dial1up and P connections, hich

enables the use of smart cards for remote users. For more information about !P1&9$,

see the !"tensible uthentication Protocol topic at

.microsoft.comresourcesdocumentationindos"pallproddocsen1

usautheap.msp"

For more information about !P certificate reuirements, see (ertificate +euirements

hen you use !P1&9$ and P!P ith !P1&9$ at

http:support.microsoft.comdefault.asp"Oscid4bRen1usR;%8-


38/56

3" The 6icrosoft Secure Access using Smart Cards lanning +uide

/r)aniDations can )ain benefits from the implementation of $ for +U$

authentication ith smart cards, hich include:

A (entraliDed user authoriDation and authentication

A $eparate mana)ement and accountin) mechanisms

A *ide ran)e of authoriDation and authentication options

&he $ ser#er mana)es the authentication process. $ deli#ers the user=s

authentication reuest and lo)on certificate information to cti#e irectory, hich

compares the lo)on certificate to the stored certificate information for that remote user. f

the certificate information matches, cti#e irectory authenticates the user.

For more information about a desi)n solution that uses $, see the >esi)nin) the

$olution> section later in this chapter.

istribution and the 'nrollment of the Smart Cards for#emote Access

&he distribution and enrollment of smart cards for remote access follos a process

similar to that for the administrator account solution as described in (hapter -, >Usin)

$mart (ards to 3elp $ecure dministrator ccounts.> &he main differences are thehi)her number of users and that the process mi)ht ta4e place in multiple

countriesre)ions.

&he #erification of the remote userNs identity is still an important part of the process.

3oe#er, because remote users do not ha#e the same ri)hts as administrators, the use

of photo identification such as a passport or dri#erNs license should be adeuate for

identification purposes. mana)er must pro#ide Eustification before the administrator

)rants the user remote access.

!nrollment stations should still be in suitable locations, such as the personnel department

or security department, and users can report there to collect their smart cards. f a user

cannot tra#el to an enrollment station, you can use remote tools to unbloc4 and to enroll

the user and acti#ate the smart card.

&he enrollment procedure reuires an enrollment a)ent to )enerate the certificate

reuest on behalf of the user and install the resultant certificate on the smart card. &he

enrollment a)ent sends the bloc4ed smart card to the user by a secure deli#ery method.

&he user then contacts the help des4, establishes his identity, and unbloc4s the smart

card, as described in the section on cti#ation *eb $er#er in (hapter 2, >$mart (ard

&echnolo)ies.>

urther Considerations

&he introduction of secure remote access ithin an or)aniDation often results in an

increase in the number of users ho ant to use the ser#ice. /r)aniDations must re#ie

their current netor4 infrastructure and, here necessary, pro#ide additional resources.

reas to consider are:

A (ertificate re#ocation lists

A 3i)h a#ailability and bandidth

A $oftare update distribution

Certificate #e(ocation %ists

&he implementation of certificates for remote users in#ol#es chan)es to ho clients can

locate a certificate re#ocation list B(+9C to chec4 that a certificate is still #alid. &he default


39/56


Uniform +esource 9ocator BU+9C (+9 for *indos $er#er 200- points to an intranet

location, for e"ample U+9http:(ertification+oot$er#er$ame(ert!nroll

(ertificationuthorityame.crl.

For remote users, this U+9 must point to a location that is accessible from the nternet.

&his reuirement in#ol#es all issued certificates and includes both the intranet and the

e"tranet U+9s for the (+9. For more information about the customiDation of (+9s, see

the $pecify certificate re#ocation list distribution points in issued certificates topic at.microsoft.comresourcesdocumentation*indos$er#200-standardproddocsen1

ussa)($procs(P.asp.

ote: +emote computers mi)ht e"perience time1out problems if they donload the(+9 throu)h a slo connection.

Soft,are pdate istribution

&he implementation of a mechanism for the distribution of softare updates is an

important step in the pro#ision of smart cards for user access. $oftare updates include

updated (onnection Mana)er profiles and ne releases of smart card tools.

Lou can distribute softare updates by:

A !"ternally accessible *eb ser#ers that contain the updates.

A (s or U$' 4eys.

A $oftare mana)ement solutions such as $ystems Mana)ement $er#er B$M$C200-.

A !1mail messa)es that contain code1si)ned updates.

f you implement P uarantine, you can distribute (onnection Mana)er profile updates

by the use of the same method that you use to pro#ide security updates and anti#irus

softare. For more information about P uarantine, see mplementin) Suarantine

$er#ices ith Microsoft irtual Pri#ate etor4 Plannin) uide at

http:)o.microsoft.comflin4O9in4d8%-07.

&he pro#ision of (onnection Mana)er and smart card updates throu)h e"ternally

accessible *eb ser#ers enables users to donload the updates before connection to an

or)aniDationNs netor4. &he donside to this solution is that it mi)ht not be possible to

use the smart card to authenticate to the e"ternal *eb ser#er. n this case, users must

rely on user name and passord combinations to lo) on and donload updates. lthou)h

this appears to defeat the purpose of to1factor authentication, because this *eb ser#er

only pro#ides update resources, you mi)ht consider this ris4 acceptable.

&he use of (s to distribute updates is a useful method for lar)e initial rollouts, because

the cost for each ( drops hen produced in hi)h #olumes. U$' 4eys are more

appropriate for the distribution of updates on an indi#idual basis.

&he use of softare mana)ement systems such as $ystems Mana)ement $er#er 200-

to distribute softare updates reuires the computers to connect to the netor4. &hismechanism can be suitable for mobile and remote users ho connect to the 9 on a

re)ular basis, and ho use computers that are members of the or)aniDationNs domain.

3oe#er, softare update mechanisms such as $ystems Mana)ement $er#er are not

appropriate for remote users ho use their on computers from home.

Lou can e1mail updates in certain situations. &o implement this method of softare

distribution, you must pro#ide code1si)ned updates and train the users to chec4 the

#eracity of the code1si)nin) certificate.

http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_CSprocs_CDP.asphttp://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_CSprocs_CDP.asphttp://go.microsoft.com/fwlink/?LinkId=41307http://go.microsoft.com/fwlink/?LinkId=41307http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_CSprocs_CDP.asphttp://go.microsoft.com/fwlink/?LinkId=41307http://go.microsoft.com/fwlink/?LinkId=41307


40/56


41/56


6aintaining roducti(it)

!mployees often lose confidence in security1based solutions that affect producti#ity.

Users are freuently frustrated if they are unable to access netor4 resources durin) and

directly after a solution deployment. *ood)ro#e & must pro#ide alternati#e access

methods to help o#ercome these frustrations. &he folloin) list of tools pro#ides

alternati#e methods of netor4 access:

; 0utloo& -eb Access. Pro#ides the user ith secure access to e1mail throu)h a*eb broser.

; #emote es&top and Terminal Ser(ices. !mployees can use +emote es4topand &erminal $er#ices to access line1of1business applications and des4top files.

!elp es& Support

User acceptance and the inte)rity of a remote access solution often depend on the le#el

of support a#ailable. !"ecuti#es become frustrated if they spend time in support ueues.

/r)aniDations must bud)et for trainin) both the end user and support personnel.

Technical Issues*ood)ro#e ational 'an4 has identified se#eral 4ey technical issues that reuire

attention prior to the smart card for remote access deployment. &hese issues include

distribution of smart cards and smart card readers, the inte)ration of the solution into the

current netor4 ith minimal disruption, and inte)ration into the current & mana)ement

infrastructure.

; Supported smart card readers. +emote users mi)ht or4 from home on a ran)eof computers that ha#e #arious operatin) systems. &he *ood)ro#e & departmentdecided that the only supported confi)uration ould be *indos IP Professionalith $P2 or later. +emote users ho run *indos 2000 Professional had noassurances that the smart card readers ould or4 ith their computers.

; et,or& latenc). &he time that pac4ets ta4e to tra#el from client to remote access

ser#er and bac4 can cause P1secured connections to fail. &his is particularlyproblematic on satellite broadband connections. *ood)ro#e ational 'an4decided not to support remote connections that e"hibit a#era)e latency times ofmore than -00 milliseconds.

; Smart cards distribution. 'ecause *ood)ro#e ational 'an4 operates in se#eralcountriesre)ions around the orld, distribution of smart cards is both a technicalissue and a security issue. &he enrollment a)ents must be able to contact theacti#ation *eb ser#er re)ardless of hich countryre)ion they are in. lternati#ely,users mi)ht ha#e to unbloc4 smart cards throu)h a challen)eresponse system.&he challen)eresponse system mi)ht reuire de#elopment effort to create ith thesmart card #endorNs softare de#elopment 4it B$HC.

Securit) Issues

&he folloin) issues affect the security strate)y for the *ood)ro#e ational 'an4

implementation of secure remote access usin) smart cards:

; #emote access user identification. &he *ood)ro#e ational 'an4 & departmentmust #alidate the identity of remote access users durin) the smart card distributionand acti#ation process.


42/56


; Connection e$ceptions for the -oodgro(e solution. 'ecause smart cards canbecome lost, stolen, or simply for)otten, the *ood)ro#e & department mustensure that its smart card deployment solution includes a fast method to securelydistribute replacement smart cards and a method to handle e"ceptions hilereplacement cards are in transit.

Solution #e/uirements&he solution reuirement for usin) smart cards to secure remote access accounts

includes the folloin) components:

; Internet Authentication Ser(ice


43/56


; Smart card and smart card reader procurement. lthou)h *ood)ro#e ational'an4 has a mature PH in place, the ban4 ould )ain little benefit from theinstallation of the *indos for $mart (ards operatin) system onto blan4 smartcards. Most #endors offer smart cards ith the operatin) system already installedon the card. &he choice of smart cards and smart card readers from a sin)le#endor pro#ides the benefit of a sin)le point of contact for any support issues.

; S* or C card smart card readers. (reation of a standard baseline fordeployment minimiDes the cost of the installation of a smart card solution.*ood)ro#e ational 'an4 implemented a corporate policy that reuires all neportable computers to ha#e built1in smart card readers. *ood)ro#e ational 'an4has also set a common standard for the supply of U$' smart card readers. &heban4 supplies U$' card readers to employees ho use their on computers toor4 from home. *ood)ro#e has ensured continuity throu)h a contract ith thecard reader supplier to supply the same model of card readers for to years.

A Trust relationships. &he *ood)ro#e ational 'an4 smart card deployment usedthe current trust relationships beteen separate forests and any one1ay trustssuch as those beteen smaller, de#elopment team forests and the main corporateforest. &his arran)ement did not reuire any chan)es to the certificate templates.

A -indo,s Ser(er 2883 ublic 7e) Infrastructure


44/56

"8 The 6icrosoft Secure Access using Smart Cards lanning +uide

smart card readers. &he outline of the concept is that a remote access user launches a

customiDed (onnection Mana)er profile, hich prompts the user to insert a smart card

into the attached smart card reader. &he operatin) system then prompts the user to enter

a P. f the P is correct, the reader e"tracts the smart card certificate and account

information. (onnection Mana)er then ma4es a connection to the corporate remote

access ser#er and presents the credentials from the smart card. cti#e irectory

authenticates these credentials and the remote access ser#er )rants the user access tothe corporate netor4.

Solution rere/uisites

&he prereuisites for the use of smart cards to secure remote access accounts are

similar to those for the smart card solution to secure administrator accounts. Lou need to:

A (onsult users and )roups

A +ecruit the proEect team

A $et user e"pectations

A Up)rade the hardare and softare

A istribute and acti#ate smart cards securely

Consult sers and +roups

*ithin the planned cycle, you should e#aluate any current remote access solutions and

consult those ho use them. *ood)ro#e ational 'an4 operates in se#eral

countriesre)ions that all ha#e remote access users. &he initial team can#assed feedbac4

from the current remote access users and support teams to identify and en)a)e potential

users, )roups, and support staff to include in the pilots.

#ecruit the ro?ect Team

Lou must ensure that you ha#e the ri)ht personnel and s4ills to implement a proEect of

this nature. &he proEect team is li4ely to reuire input from the folloin) representati#e

occupations:

A Pro)ram mana)er

A nformation systems architect

A $ystems analyst or inte)rator

A $ystems en)ineers

A Product release mana)er

A Product testin) mana)er

A $upport or help des4 mana)er

A User support specialists

A $ecurity officers

For more information about representati#e occupations and role associations in theMicrosoft /perations Frameor4 BM/FC, see &he Microsoft $olutions Frameor4

$upplemental *hitepapers & /ccupation &a"onomy at

.microsoft.comdonloadsdetails.asp"OFamily;-


45/56

Chapter ": sing Smart Cards to !elp Secure #emote Access Accounts "1

Set ser '$pectations

&he main issue for user e"pectations ith smart card and remote access is that of the

increased lo)on times. Users must e"pect lo)on times to increase by se#eral seconds

ith smart card authentication.

pgrade the !ard,are and Soft,are

&he smart card for remote access solution reuires the latest Microsoft operatin)

systems and ser#ice pac4s. &his reuirement enables the remote access solution to ta4e

ad#anta)e of the latest ad#ances and security facilities in *indos IP Professional ith

$P2 and *indos $er#er 200- ith $P%, such as *indos Fireall, ata !"ecution

Pre#ention B!PC, $ecurity (onfi)uration *iDard, and P Suarantine.

&he softare up)rades mi)ht reuire up)rades to client or ser#er hardare. pilot

pro)ram can establish hether older euipment can run the neer operatin) systems. &o

chec4 hether euipment is certified for *indos IP or *indos $er#er 200-, see the

Products esi)ned for Microsoft *indos *indos (atalo) and 3(9 topic at

.microsoft.comhdchcldefault.msp"O)ssnb%.

istribute and Acti(ate Smart Cards Securel)

mplementation of smart cards for remote access reuires a secure method for smart

card distribution and acti#ation. &ypically, this distribution process ould reuire remote

users to report to their local administrati#e office so that the enrollment a)ent can #erify

their identity, issue the smart card, and carry out the acti#ation procedure. &he ele)ated

ssuance Model section later in this chapter describes ho *ood)ro#e ational 'an4

distributed and acti#ated smart cards for remote users.

Solution Architecture

&he implementation of the *ood)ro#e ational 'an4 smart card solution for remote

access reuires the folloin) components:

A cti#e irectory

A $ installed on a *indos $er#er 200- ser#er

A *indos $er#er 200- ith $P% ith routin) and remote access

A roup Policy

A (lient computers that run *indos IP Professional ith $P2 or later

A $mart card readers

A $mart cards ith at least -2 H' memory

A (onnection Mana)er profiles created ith (MH

A (lient1side scripts for the (onnection Mana)er profile

&he *ood)ro#e & department initially considered the pro#ision of support for all currently

deployed #ersions of *indos. 3oe#er, the increased aareness of the threat to

computers connected to the nternet led them to standardiDe on *indos IPProfessional ith $P2 or later.

User accounts and )roup memberships stored in cti#e irectory re)ulate remote

connecti#ity and access to corporate resources at *ood)ro#e ational 'an4. *ood)ro#e

& also uses P/s for the confi)uration of client computers to meet corporate netor4

security policies.

http://www.microsoft.com/whdc/hcl/default.mspx?gssnb=1http://www.microsoft.com/whdc/hcl/default.mspx?gssnb=1


46/56

"2 The 6icrosoft Secure Access using Smart Cards lanning +uide

!o, the Solution -or&s

&his section pro#ides technical details of the *ood)ro#e ational 'an4 solution. t

e"plains ho cti#e irectory authenticates the user and traces the authentication path

for the smart card credentials.

&he folloin) procedure enables remote access ith smart cards:

%. remote user lo)s onto a computer that has nternet access and a smart cardreader attached. &he user initiates the customiDed (onnection Mana)er profile bydouble1clic4in) on the connection labeled -oodgro(e IT Connection 6anagerfor smart cards.

2. &he (onnection Mana)er profile chec4s for a smart card in the smart card reader. dialo) bo" appears that prompts the user to enter the P. (onnection Mana)eruses the P to perform 4ey operations on the card as a system ser#ice because itcannot prompt and sho the user interface BUC on the des4top. f the user entersthe correct P, the card unloc4s and allos the remainder of the remote accesslo)on process to continue.

-. &he 9ocal $ecurity uthority B9$C is the trusted operatin) system component thatperforms all authentications. $(hannel, the code that implements $$9, runs partly

in the 9$ and initiates the mappin) seuence.8. &he (onnection Mana)er profile initiates a lin4 to the $ ser#ers at *ood)ro#e

ational 'an4 usin) a dial1up or P connection. &he $ ser#er performs are#ocation chec4 on the client certificate. *ith the certificate mappin) to the userprincipal name BUPC, the issuin) ( must be in the &U&3 store. !"plicitmappin) can also be set on the cti#e irectory user account.

5. &he 9$ presents the user information to the $ ser#er. &he $(hannel code thatruns on the $ ser#er sends a messa)e to the $(hannel code that resides on thedomain controller and passes it the UP information from the certificate.

6. &he $(hannel code that runs on the $ ser#er #alidates the certificate and thendoes a user loo4up a)ainst the cti#e irectory on the domain controller. &hedomain controller )enerates a Pri#ile)e ccess (ertificate BP(C that contains theuserNs %2;1bit identifier and the )roup membership of the user. Futurecommunications from this point uses the Herberos #5 protocol.

7. &he domain controller transmits a randomly )enerated session 4ey that includesthe Herberos &ic4et rantin) &ic4et B&&C to the client computer. +eceipt of this4ey authenticates the remote access ser#er to the client. 'oth computers ha#e nomutually authenticated.

;. &he client computer decrypts the lo)on session 4ey and presents the Herberos #5&& to the tic4et )rantin) ser#ice. fter this process completes, all other Herberos#5 protocol communication uses symmetric encryption.


47/56


&he folloin) fi)ure illustrates the steps to use a smart card for remote access

authentication.

igure ".1

Remote access logon and authentication process that uses a smart card&he additional processor cycles reuired to process the smart card information adds

appro"imately 20 to 25 seconds to the initial authentication process. fter authentication

is complete, performance is not affected.

Additional esign Considerations

&he ne"t section details additional considerations for smart card deployment, and

includes the smart card distribution mechanism that *ood)ro#e ational 'an4 used.

elegated Issuance 6odel

&he *ood)ro#e ational 'an4 & department de#eloped a dele)ated issuance model for

smart cards. &his model offers responsi#e support that helps to ensure the hi)hest le#el

of security for the distribution of smart cards to employees around the orld.

*ood)ro#e ational 'an4 & used a dele)ated issuance model to deploy smart cards

outside the main *ood)ro#e ational 'an4 & center in 9ondon. &he *ood)ro#e

ational 'an4 & department sent technicians to offices around the orld to train the

dele)ated issuance officers B/sC. &he technicians trained the /s on ho to distribute

smart cards and ho to use the smart card tools. fter the initial #isit, the /s

participated in ee4ly conference calls ith the *ood)ro#e ational 'an4 central & team

to discuss issues that emer)e.


48/56

"" The 6icrosoft Secure Access using Smart Cards lanning +uide

&he folloin) fi)ure illustrates the steps that ma4e up the dele)ated issuance model for

certificate reuest appro#al.

igure ".2The smart card delegation process used to issue smart cards for remote access

&he steps performed in accordance ith this flochart are:

%. User reuests a smart card from the /.

2. &he / #alidates the user=s identity a)ainst an acceptable form of identification,such as a passport or a dri#erNs license and chec4s the userNs identity ith thehead of department. fter the / confirms the userNs identity, the / submits acertificate reuest to the security officer in 9ondon.

-. &o #alidate the reuest, the security officer chec4s for any prior certificates issuedin that user=s name. &he security officer also determines if the user has made anyother smart card reuests. f there is no obEection to issue the smart card, thesecurity officer )i#es appro#al. f the security officer unco#ers a problem, theprocess must be subEect to an audit, as described in step fi#e.

8. &he / recei#es the appro#al and uses the enrollment a)ent account to issue thecertificate. &his certificate attaches to a ne smart card, hich the / issues tothe user in person. &he dele)ated issuance process then completes.

5. f there are concerns o#er the #alidity of the reuest, the security officer initiates anaudit of the reuest to determine hether to )rant appro#al for that user. fter theaudit concludes, the user must ma4e a ne reuest.

6. &he dele)ated issuance process completes.

*ood)ro#e ational 'an4 could only implement the dele)ated issuance model after

*ood)ro#e & mi)rated the corporate certificate authorities to *indos $er#er 200-. &he

*indos $er#er 200- PH pro#ides the ability to apply detailed permissions to sections of

the certificate templates, hich enables the role of /s ithin the dele)ated issuance


49/56


model. *ithin the issuance model, *ood)ro#e de#eloped procedures to securely reissue

lost or stolen smart cards.

Configure #AIS Accounting

lthou)h the maintenance of lo)s is not a reuirement for the implementation of a remote

access solution that uses smart cards, Microsoft stron)ly recommends it. f you use $,

one benefit is the built1in support for the +U$ accountin) pro#ider, hich lo)s clientconnection reuests and sessions. *ood)ro#e ational 'an4 ants to monitor hich

users lo) on, hen they lo) on, and for ho lon) they connect to the corporate netor4.

+U$ )i#es *ood)ro#e the capability to analyDe connection trends, ith the aim to

re#ie and impro#e the ser#ice.

!ach $ ser#er collects user session data, hich it stores in Microsoft $S9 $er#erG

es4top !n)ine B*indosC B*M$!C on *indos $er#er 200- or on $S9 $er#er 2000

es4top !n)ine BM$! 2000C on *indos 2000 $er#er and earlier. $ transfers the

accountin) information from *M$! or M$! to a central $S9 $er#er 2000 database in

near real time. &his arran)ement ensures cost1effecti#e use of $S9 $er#er licensin) and

does not inhibit the ser#erNs performance.

*ood)ro#e ational 'an4 deployed re)ional $S9 $er#er based data collection ser#ers

to collect $ remote access session data.

eplo) ilots

*ood)ro#e ational 'an4 & tests any solution in both a lab en#ironment and more than

one pilot before deployment to the production netor4. *ood)ro#e & de#eloped to

pilots for the remote access smart card deployment: one in#ol#ed a small but

e"perienced )roup of users and the other included a more di#erse )roup of users in

se#eral countriesre)ions ith a ide ran)e of remote access e"perience.

&he pilot ith the more e"perienced users enabled *ood)ro#e ational 'an4 to identify

the maEor problems ith the smart card deployment. &he more e"perienced users ere

able to cope ith minor disruptions and une"pected dialo) bo"es. fter the *ood)ro#e &

department completed the first pilot, they 4ne that the smart card solution ould or4

but that some refinement as necessary.

&he second pilot ith the di#erse ran)e of users enabled the *ood)ro#e & department

to e"perience the sort of support calls e"pected from the full deployment. &his pilot

enabled the help des4 to resol#e technical issues and indicated any further de#elopment

that mi)ht be reuired before the deployment of smart cards to all remote users.

'nsuring !igh A(ailabilit)

&he solution scenario must be hi)

smart cards planning

Documents