SIG-SS-16x-B.pdf

ARIA Radiation Therapy Management System ® 16.x
Security Implementation Guide
SIG-SS-16X-B JUNE, 2020

Format TMP-GE-MANUAL-B
2 of 53 SIG-SS-16x-B
MANUFACTURER Varian
3100 Hansen Way, Bldg. 4A
Palo Alto, CA 94304-1030, U.S.A.
EUROPEAN
REPRESENTATIVES
Varian Medical Systems Nederland B.V.
Kokermolen 2
3994 DH Houten
The Netherlands
NOTICE Information in this document is subject to change without notice and does not
represent a commitment on the part of Varian. Varian is not liable for errors contained
in this document or for incidental or consequential damages in connection with the
furnishing or use of this material.
This document contains proprietary information protected by copyright. No part of this
document may be reproduced, translated, or transmitted without the express written
permission of Varian Medical Systems, Inc.
TRADEMARKS Varian products referenced herein are either registered trademarks or trademarks of
Varian Medical Systems in the U.S. and/or other countries. The names of other
companies and products mentioned herein may be the trademarks of their respective
owners. Any rights not expressly granted herein are reserved.
CONTACTING
SUPPORT
Support services are available without charge during the initial warranty period. If you
seek information not included in this publication, contact Varian support with the
following number or link:
Telephone support – 1.888.VARIAN5 (1.888.827.4265)
For International telephone numbers - Varian Contacts
To contact the support location nearest you for service, parts, or support, see the list at
the Varian Medical Systems website: VMS Worldwide Contacts
You may use MyVarian for all means of contacting Varian. Click Contact Us. No
registration is required but is recommended.
If you are unable to access MyVarian, use the following email address for support:
support@varian.com
COPYRIGHT 2020 Varian Medical Systems, Inc. All rights reserved. It is strictly prohibited to copy
this document or disclose the contents to unauthorized recipients.

TABLE OF CONTENTS
1 Introduction .....................................................................................................................................................5
1.1 Conventions.............................................................................................................................................5
2 Reference Information ....................................................................................................................................6
2.1 Revision Information................................................................................................................................6
2.2 Scope ......................................................................................................................................................6
2.2.1 About this Guide..........................................................................................................................6
2.2.2 Who should read this guide?.......................................................................................................6
2.2.3 Targets ........................................................................................................................................7
2.3 System Requirements .............................................................................................................................7
2.4 References ..............................................................................................................................................7
2.5 Abbreviations...........................................................................................................................................7
3 Security Concept ............................................................................................................................................9
3.1 Quick Reference......................................................................................................................................9
3.2 Active Directory Environment Design Guidelines ..................................................................................10
3.2.1 Active Directory User Reference ...............................................................................................12
3.2.2 Local dicomdaemon User for TrueBeam 2.7 or Lower..............................................................14
3.2.3 Permissions Granularity ............................................................................................................14
3.2.4 Domain and Forest Functional Levels .......................................................................................15
3.3 New Security Features ..........................................................................................................................20
3.3.1 Database Access and Application Roles...................................................................................20
3.3.2 Specific Requirements for Services...........................................................................................22
3.3.3 SSL Communication AND Certificates ......................................................................................24
3.3.4 Firewall Configuration................................................................................................................27
3.3.5 Access to Domain Resources from Non-Domain Computers ...................................................28
4 Active Directory Environment Security Reference........................................................................................29
4.1 Security Requirements ..........................................................................................................................29
4.1.1 Security Requirements for Installation.......................................................................................29
4.1.2 Security Requirements for Runtime...........................................................................................29
4.2 Server Reference ..................................................................................................................................29
4.2.1 Directories Used by Varian Applications ...................................................................................29
4.2.2 <VMSOS_DATA_ROOT> Directory ..........................................................................................30
4.2.3 <VMSOS_PROGRAM_ROOT> Directory .................................................................................31
4.2.4 <VARIAN_FILE_DATA> Directory ............................................................................................32
4.2.5 <VA_TRANSFER> Directory.....................................................................................................33
4.2.6 Dose Calculation Framework <DCF> Directory ........................................................................36
4.2.7 <VA_GATING> Directory ..........................................................................................................38
4.3 Client Reference....................................................................................................................................40
4.3.1 <VMSOS_DATA_ROOT> Directory ..........................................................................................40
4.3.2 <VMSOS_PROGRAM_ROOT> Directory .................................................................................41

5 Implementing Security ..................................................................................................................................42
5.1 Implementation......................................................................................................................................42
5.1.1 Remove Unused Share .............................................................................................................42
5.1.2 Migrate OSP Users....................................................................................................................42
5.1.3 Checklist for Server Configuration.............................................................................................42
5.2 Implementation Using Scripts................................................................................................................43
5.3 Manual Security Configuration for Windows..........................................................................................47
5.3.1 Manually Creating an AD Organizational Unit (OU) ..................................................................47
5.3.2 Manually Creating Users ...........................................................................................................47
5.3.3 Manually Creating Groups.........................................................................................................48
5.3.4 Manually Add Users or Computers to Groups...........................................................................48
5.3.5 Manually Setting Permissions on Directories ............................................................................49
5.3.6 Manually Setting Permissions on Shares ..................................................................................49
5.3.7 Reset File Permissions to Default Permissions.........................................................................50
6 Security Troubleshooting ..............................................................................................................................51
6.1 Auditing File and Folder Access............................................................................................................51
6.2 Auditing NTLM Authentication...............................................................................................................53

1 Introduction
1.1 Conventions
These are the types of notes and precautionary notices along with their icons which are used in this document.
WARNING
A WARNING describes actions or conditions that can result in serious injury
or death.
CAUTION
A CAUTION describes actions or conditions that can result in minor or
moderate injury.
NOTICE
A NOTICE describes actions or conditions that can result in equipment
damage, non-compliant operation, and / or other significant issues that do not
involve injury.
A Stop describes actions or conditions that must be verified and / or satisfied before continuing.
A Note describes actions or conditions that help the user obtain optimum performance from the
equipment or software.
A Tip describes actions or conditions that simplify, improve, or assist the end user with the
required steps.
Place
image
here
An Icon box shows the user an image of the icon, button, app quick start, or other object to be
used and describes the objective or instructs how it should be used. This is a new table type.

2 Reference Information
2.1 Revision Information
REVISION INFORMATION
REV DATE DESCRIPTION OF CHANGE AUTHOR NAME
B 12 Jun 2020
AURA reports user updated & VarianTransfer User
removed
Joseph Tolentino
A 27 Nov 2019 Initial release João Almeida
2.2 Scope
2.2.1 About this Guide
This guide is intended to help design and implement data security and access permissions for ARIA in different
hospital environments. Its purpose is to protect patient data and allow a defined application environment for
Varian software. This guide focuses primarily on security for the ARIA Radiation Therapy Management
System, from here on designated just ARIA or ARIA Information System and does not include security settings
unique to subcomponents of Treatment Planning or Treatment Delivery Systems.
The owner of the local IT environment shall be the customer, and as such it is the responsibility of the
customer to supply and configure an appropriate Windows Domain environment suitable to host the ARIA
Information System. This guide provides guidelines for this Windows Domain environment and associated
settings. Varian specific configuration shall be integrated into the existing setup.
ARIA v16.x introduces a new approach to user and application access control, based on a new security
implementation. This guide presents these changes and the necessary environment configuration to run ARIA
v16.x.
Data security and access permissions described in this document represent the recommended security
configuration, aiming to minimize manual configuration steps and at the same time, supply an appropriate level
of security and access control. A customer representative may choose to implement and take responsibility for
a distinct security implementation.
The present guide is applicable to all subsequent v16.x versions.
2.2.2 Who should read this guide?
The intended audience is the hospital’s IT Service Personnel and Varian Service Representatives.
This document can be distributed to the hospital IT personnel before an installation or upgrade takes place in
order to provide necessary information to assist during the installation or upgrade.
CAUTION
This document is subject to change without notice.
The installation requires an advanced knowledge of personal computers and
Windows operating systems, and network experience.

2.2.3 Targets
The following are the main targets for applying access and file permissions in the ARIA Environment:
• Patient images and related DICOM files must be accessible from all Varian-licensed applications
• Patient images and related DICOM files must be secured against unauthorized access
• Utilization of centralized items:
• Common ARIA System Server and hosted databases
• Common ARIA application files on a server
• Central system configuration on the Shared Framework Server
• Ease of installation/upgrade as well as service
There is no requirement for a Varian client workstation to access any resource on the hospital network other
than those resources provided for ARIA applications.
2.3 System Requirements
ARIA requires a Windows 2012 or 2016 Server Domain. If possible, the hospital’s existing domain controllers
shall be used. If High Availability and Rapid Recovery Protection (HARRP) has been implemented, then Active
Directory services (e.g.: Domain Controller) should not be installed on any HARRP-source devices (i.e. image
servers or database servers). For detailed information about HARRP please contact Varian Service.
NOTICE
Reverse DNS lookup must be allowed by the DNS server(s) in order to ensure
the correct operation of the client applications.
2.4 References
[1] P1037893xxx System Server Media (Backup and Security)
[2] SIM-PM-AURA15xNEW: ARIA Unified Reports v15.x Software Installation Manual
[3] SIM-SF-160: Shared Framework Software Installation Manual
2.5 Abbreviations
AD Active Directory
CSS Customer Support Services
DCF Dose Calculation Framework
DICOM Digital Imaging and Communications in Medicine
GPO Group Policy Object
IIS Microsoft Internet Information Services
KDC Kerberos Domain Controller
MICAP Mission Critical Application Protection
MMC Microsoft Management Console
ODBC Open Database Connectivity
OU Organizational Unit
RPM Real-time Position Management™

RSD Remote Software Deployment
RGSC Respiratory Gating for Scanners
RT Radiation Therapy
SF Shared Framework (former OSP)
SSL Secure Socket Layer
TDS TrueBeam Delivery System
TLS Transport Layer Security
VSS Varian System Server

3 Security Concept
The new security implementation in ARIA 16.x is based on Windows Active Directory integration, and
introduces numerous security features and changes to previous versions:
• All ARIA applications, including VSS use Windows Authentication with AD credentials of logged in users.
Application accounts are no longer necessary in ARIA.
• All accounts used in ARIA can be managed by local IT. User and password management is removed from
Varian applications.
• User rights in ARIA are still managed by Shared Framework (former OSP).
• Protected communication over SSL between ARIA sub-systems, requiring installation of certificates.
• Database access based on application roles.
• All services run as Network Service, including web-services, DICOM Services and DCF agents.
• Firewalls should be enabled. Application installers create the necessary rules.
With AD integration, it is possible that the user logged in to Windows and ARIA applications are
different and may have different user rights. This may mean that the Printers and/or other
resources are accessible directly from Windows but unavailable from within ARIA applications.
3.1 Quick Reference
TABLE 1: QUICK REFERENCE
Domain Users and Groups
All Varian application users’ domain accounts must be included in ‘Varian
Application Users’ group.
Refer to Chapter 3 Section 3.2 Active Directory Environment Design
Guidelines.
Refer to Chapter 5 Section 5.1 Implementation for Domain setup
instructions.
Service Configuration
All services, including web-services, DICOM and DCF services should
run under the Network Service account.
Refer to Chapter 3 Section 3.3.2 Specific Requirements for Services for
details.
Firewall Configuration
Firewall should be enabled on all machines. Applications installers create
the necessary rules.
Refer to Chapter 3 Section 3.3.4 Firewall Configuration for details.
Database access
Varian Application Users group must exist as a login in the MS SQL
server.
Refer to Chapter 3 section 3.3.1 Database Access and Application Roles
for details.
File Share access
Varian Application Users groups must have Read and Modify
permissions to all file shares.
Refer to Chapter 4 section 4.2 Server Reference for details.

3.2 Active Directory Environment Design Guidelines
This chapter gives an overview of the relations between the different groups and users and their properties.
Figure 1: AD Security Guideline
The proposed user group configuration shown in Figure 1: AD Security Guideline is based on two resource
groups and two user groups.
The resource groups ‘Varian Application Users’ and ‘Varian Administrators’ are used to configure permissions
to Varian resources.
The user groups ‘Varian Computers’ and ‘Varian Users’ are containers for the security principals that require
access to Varian resources and allow for an easy organization given by the separation between Domain users

and Domain computers. Both user groups are members of ‘Varian Application Users’ resource group, since
both require similar access to Varian resources provided by this group.
The ‘Varian Users’ group includes all the Active Directory users that intend to work with ARIA applications.
The ‘Varian Computers’ group includes all machines in the Varian Information System that run Web Services
or Windows Services. This includes, if existent, the Web server, SF server, DB server, Daemon servers, DCF
or FAS servers, DCF agents and DICOM Worklist workstation/server.
The ‘Varian Administrators’ resource group has additional permissions to Varian resources. These permissions
are required by Varian Service personal to install, maintain and troubleshoot Varian software applications.
TABLE 2: DOMAIN SECURITY GROUPS AS SHOWN FIGURE 1: AD SECURITY GUIDELINE
RESOURCE
GROUP NAME
VARIAN
APPLICATION
USERS
VARIAN
ADMINISTRATORS
VARIAN USERS VARIAN
COMPUTERS
Description Resource Group
used to control
access to Varian
resources
Resource Group
used by Varian
Service to
administer Varian
resources
Users Group
including all Domain
users that access
Varian applications
Users Group
including all
Domain computers
that run Varian
services
Group scope Domain Local Domain Local Domain Global Domain Global
Member of: Varian Applications
Users
Varian Applications
Users
NOTICE
Some Varian applications and devices, not part of ARIA RTM, still require
specific user accounts to be created. This is the case for AURA, RPM and
RGSC.
CAUTION
Windows workgroup environment is no longer supported by Varian. The only
exception is the single machine environment (T-Box) which does not need to
be part of a domain.
TABLE 3: SUPPORTED ARCHITECTURAL ENVIRONMENT
ARCHITECTURE WORKSTATIONS SUPPORTED OPERATING SYSTEMS
Windows Server Domain Client Windows® 10 (build 1607)
Server Windows Server® 2012 R2
Windows Server® 2016
If the Varian system is to be integrated into an existing hospital AD domain, then a ‘Varian’ Organizational Unit
(OU) is required.
Domain-wide Group Policies within the domain should NOT be used against this OU (block inheritance to the
OU), but if non-restrictive policies are required (such as account and password policies), these can be
applied through a GPO specifically for that OU.
Additionally, domain policies should NOT be used to apply the file and registry permissions, as this could
constitute a change to a medical device each time a user logs on. Permissions should be applied explicitly as
defined in this guide.

Using a ‘Varian’ domain overcomes these problems, as domain policies do not have an effect outside of the
domain in which they are created. For this reason and others, a separate ‘Varian’ domain is the preferred
configuration; as it means the radiotherapy department and Varian have control over the policies applied to the
servers and workstations used for Radiotherapy.
CAUTION
If domain polices are applied, then Varian will accept no responsibility for
issues that are found to be caused by the implementation of restrictive
policies onto the domain or domain OU. This situation could seriously impact
a successful installation.
3.2.1 Active Directory User Reference
All users that intend to work with or interact in any way with ARIA RTM applications must exist as domain user
accounts. Such user accounts also need to exist in Varian Service Portal (former OSP), where user rights for
ARIA applications are managed.
When upgrading from pre-v15 versions, Shared Framework provides a Users Mapping Tool to
facilitate matching former OSP users with domain user accounts. Please refer to SIM-SF-160 for
instruction on running this tool. This is not required for v15 and up.
In addition to regular ARIA user domain accounts, a limited number of service and application accounts is
necessary. The VarianService, VarianInstaller and VarianTrainer accounts are required to support the
activities of Varian CSS personnel. The VarianGating is used by gating applications RPM and RGSC to
access domain resources. The SsisUser and ReportsUser are used by AURA to access the VARIAN
database. The VarianInsightive user should be used for Insightive DB installation, InSightive Server
configuration (tableau) and InSightive Server Components installation.
TABLE 4: USERS
USERS: INTERACTIVE PURPOSE PERMISSIONS USERS GROUP
VarianService Yes Varian system
administration and
maintenance
Full permissions on
Varian resources
(Local Admin)
Varian Administrators
VarianInstaller Yes Varian system
installation and
configuration
Preferably Domain
Admin, otherwise
Local Admin
VarianTrainer Yes Customer Training Execute Varian
applications
Varian Users
VarianGating No For RPM and
RGSC access to
domain
Access to new
VA_GATING$
share and
VA_TRANSFER
share
NA
VarianSsisUser
(AURA)
No Migrate data to
AURA DB and run
incremental jobs.
See note below for
password
guidelines.
Access to Varian
System Server DB
and variandw DB
NA

TABLE 4: USERS
USERS: INTERACTIVE PURPOSE PERMISSIONS USERS GROUP
VarianReportsUser
(AURA)
No Execute AURA
reports
Access to Varian
System Server DB
and variandw DB
Needs log on
locally only on aura
server not local
admin
NA
VarianInterface Yes ARIA Connect Preferable Domain
Admin, otherwise
Local Admin
VarianIntEngine No Interface Service
Account
Access to Varian
System Server DB
NA
CrystalReports No ODBC Connection
for Crystal Reports
Access to Varian
System Server DB
NA
VarianInSightive Yes Tableau user Read-only access
to Varian DB and
read-write access
to variandw DB.
NA
LinacNetworkAccess
(username cannot be
changed for Halcyon)
No To mount domain
shares behind
MICAP (for
Halcyon,Truebeam
2.8 and above)
Access to
VA_TRANSFER
share
NA
Equicare No Used by Equicare
to access ARIA
Full permission on
Varian resources
(Local admin)
Poller No Used to run Direct
Message Poller
service
Full permissions on
Varian resources
(Local admin)
dicomdaemon (local
user)
No Varian DICOM
Daemon User
(Truebeam up to
2.7)
Local user with
access to
VA_TRANSFER
share
NA
VarianBackupUser Yes To take backup of
servers
Local admin on
servers intended
for backup for full
access of servers
NA
ErxClient No Used by Unlimited
Systems to access
ARIA
Full permission on
Varian resources
(Local admin)
HCIUser No Cloverleaf CIS/SS
service for ARIA
Connect
Local user NA

NOTICE
SSISUser password must not contain the following special characters:
- Double quotes (“)
- Double hyphen (--)
- At symbol (@)
- Single quite (‘)
- Forward slash followed by an Asterix (/*)
NOTICE
DB Permissions for AURA users are automatically configured during AURA
installation. Please refer to SIM-PM-AURA15xNEW for details.
NOTICE
It is strongly recommended to use strong and cryptic passwords for the
service accounts (non-interactive users). These passwords should remain
unchanged. If a password change is required, this needs to be coordinated
between local IT / Customer / Varian to ensure system availability after the
change.
3.2.2 Local dicomdaemon User for TrueBeam 2.7 or Lower
To support the functionalities of TrueBeam 2.7 or lower (ie: access to I-drive and PeerSync operation) a local
user “dicomdaemon” needs to be created. The guideline for creating the user is as follows.
• A local user named ‘dicomdaemon’ on the server hosting the va_transfer share will be required for sites
or facilities that have a TrueBeam 2.7 or lower.
• The password for ‘dicomdaemon’ shall be determined by the Customer.
• Varian highly recommends the use of a strong, complex, and non-easily guessable password for this
dicomdaemon local user.
• The ‘dicomdaemon’ user does not need to be a local administrator.
• The ‘dicomdaemon’ user must have full access to the va_transfer file share – the directory the share is
on and all its subfolders.
3.2.3 Permissions Granularity
The recommendation is to use simple permissions rather than special permissions in order to simplify the
access control of the ARIA environment. Therefore, wherever possible, no special permissions are expected.
In general, when read permissions are assigned one can also execute applications and with write permissions,
one can also delete objects.

3.2.4 Domain and Forest Functional Levels
Figure 2: AD Objects Overview
In Windows Server 2003, functional levels were an extension of the older mixed/native mode concept
introduced in Windows 2000. In Windows Server 2008, 2008R2, 2012 and 2012 R2 this was further extended
to include new features and benefits. Functional levels define the features of Active Directory Domain Services
(AD DS) that are enabled in a domain or forest.
If the Active Directory is running on Windows Server 2012 R2 it can be configured on functional level of 2003,
2008, 2008R2, 2012 or 2012 R2. Please see the Windows server domain documentation about detailed
information on the different supported features.
NOTICE
Forest functionality activates features across all the domains in a forest.
Domain functionality activates features for a particular domain only.
3.2.4.1 Features That Are Enabled at Domain Functional Levels
The following table taken from Windows Active Directory Help lists the enabled features and supported
domain controller operating systems for each domain functional level.

TABLE 5: DOMAIN FUNCTIONAL LEVEL FEATURES. MICROSOFT ACTIVE DIRECTORY DOMAIN
SERVICE
DOMAIN
FUNCTIONAL
LEVEL
ENABLED FEATURES SUPPORTED
DOMAIN
CONTROLLER
OS
Windows 2000
native
(not supported in
Windows Server
2012 / 2012R2)
All default Active Directory features, plus the following features:
Universal groups for both distribution groups and security groups
Group nesting
Group conversion, which makes conversion possible between
security groups and distribution groups
Security identifier (SID) history
W2K
W2K3
W2K8
W2K8R2
Windows Server
2003
All default Active Directory features, all features from the Windows
2000 native domain functional level, plus the following features:
The domain management tool, Netdom.exe, is available to prepare
for domain controller rename.
Logon time stamp update. The lastLogonTimestamp attribute will be
updated with the last logon time of the user or computer. This
attribute is replicated within the domain. Note that this attribute
might not be updated if a read-only domain controller (RODC)
authenticates the account.
The userPassword attribute can be set as the effective password on
inetOrgPerson objects and user objects.
Users and Computers containers can be redirected. By default, two
well-known containers are provided for housing computer and
user/group accounts:
cn=Computers,<domain root> and
cn=Users,<domain root>.
With this feature, you can define a new well-known location for
these accounts.
Authorization Manager can store its authorization policies in AD DS.
Constrained delegation, which makes it possible for applications to
take advantage of the secure delegation of user credentials by
means of the Kerberos authentication protocol. You can configure
delegation to be allowed only to specific destination services.
Support for selective authentication, which makes it possible to
specify the users and groups from a trusted forest who are allowed
to authenticate to resource servers in a trusting forest.
W2K3
W2K8
W2K8R2
W2012
W2012R2

SERVICE
DOMAIN
FUNCTIONAL
LEVEL
DOMAIN
CONTROLLER
OS
Windows Server
2008
2000 native and the Windows Server 2003 domain functional levels,
plus the following features:
Distributed File System (DFS) Replication support for SYSVOL,
which provides more robust and detailed replication of SYSVOL
contents. You may need to perform additional steps to use DFS
Replication for SYSVOL. For more information, see File Services
(http://go.microsoft.com/fwlink/?LinkId=93167).
Advanced Encryption Services (AES 128 and 256) support for the
Kerberos protocol.
Last Interactive Logon Information, which displays the time of the
last successful interactive logon for a user, from what workstation,
and the number of failed logon attempts since the last logon.
Fine-grained password policies, which make it possible for
password and account lockout policies to be specified for users and
global security groups in a domain.
W2K8
W2K8R2
W2012
W2012R2
Windows Server
2008 R2
2000 native, Windows Server 2003, and Windows Server 2008
functional levels, plus the following feature:
Authentication Mechanism Assurance, which packages information
about the type of logon method (smartcard or user name/password)
that is used to authenticate domain users inside each user’s
Kerberos token. When this feature is enabled in a network
environment that has deployed a federated identity management
infrastructure, such as Active Directory Federation Services (AD
FS), the information in the token can then be extracted whenever a
user attempts to access any claims-aware application that has been
developed to determine authorization based on a user’s logon
method.
W2K8R2
W2012
W2012R2
Windows Server
2012
The Kerberos Domain Controller (KDC) support for claims,
compound authentication, and Kerberos armoring KDC
administrative template policy has two settings (Always provide
claims and fail unarmored authentication requests) that require
Windows Server 2012 domain functional level. For more
information, see What's New in Kerberos Authentication.
W2012
W2012R2

SERVICE
DOMAIN
FUNCTIONAL
LEVEL
DOMAIN
CONTROLLER
OS
Windows Server
2012 R2
Domain Controller side protections for Protected Users. Protected
Users authenticating to a Windows Server 2012 R2 domain can no
longer:
Authenticate with NTLM authentication
Use DES or RC4 cipher suites in Kerberos pre-authentication
Be delegated with unconstrained or constrained delegation
Renew user tickets (TGTs) beyond the initial 4 hour lifetime
Authentication Policies:
New forest-based Active Directory policies which can be applied to
accounts in Windows Server 2012 R2 domains to control which
hosts an account can sign-on from and apply access control
conditions for authentication to services running as an account.
Authentication Policy Silos:
New forest-based Active Directory object, which can create a
relationship between user, managed service and computer,
accounts to be used to classify accounts for authentication policies
or for authentication isolation.
W2012 R2
3.2.4.2 Features That Are Enabled At Forest Functional Levels
The following table lists the enabled features and supported domain controller operating systems for each
forest functional level.
TABLE 6: FOREST FUNCTIONAL LEVEL FEATURES. MICROSOFT ACTIVE DIRECTORY DOMAIN
SERVICE
FOREST
FUNCTIONAL
LEVEL
DOMAIN
CONTROLLER
OS
Windows 2000
(not supported in
Windows Server
2012 / 2012R2)
All default Active Directory features W2K
W2K3
W2K8
W2K8R2

SERVICE
FOREST
FUNCTIONAL
LEVEL
DOMAIN
CONTROLLER
OS
Windows Server
2003
All default Active Directory features, plus the following features:
Forest trust
Domain rename
Linked-value replication (changes in group membership to store and
replicate values for individual members instead of replicating the
entire membership as a single unit). This change results in lower
network bandwidth and processor usage during replication, and it
eliminates the possibility of lost updates when different members are
added or removed concurrently at different domain controllers.
The ability to deploy an RODC
Improved Knowledge Consistency Checker (KCC) algorithms and
scalability. The intersite topology generator (ISTG) uses improved
algorithms that scale to support forests with a greater number of sites
than can be supported at the Windows 2000 forest functional level.
The ability to create instances of the dynamic auxiliary class called
dynamicObject in a domain directory partition
The ability to convert an inetOrgPerson object instance into a User
object instance, and the reverse
The ability to create instances of the new group types, called
application basic groups and Lightweight Directory Access Protocol
(LDAP) query groups, to support role-based authorization
Deactivation and redefinition of attributes and classes in the schema
W2K3
W2K8
W2K8R2
W2012
W2012R2
Windows Server
2008
All the features available at the Windows Server 2003 forest
functional level, but no additional features. All domains that are
subsequently added to the forest, however, will operate at the
Windows Server 2008 domain functional level by default.
If you plan to include only domain controllers that run Windows
Server 2008 or Windows Server 2008 R2 in the entire forest, you
might choose this forest functional level for administrative
convenience.
W2K8
W2K8R2
W2012
W2012R2

SERVICE
FOREST
FUNCTIONAL
LEVEL
DOMAIN
CONTROLLER
OS
Windows Server
2008 R2
All of the features that are available at the Windows Server 2003
forest functional level, plus the following feature:
Recycle Bin, which provides the ability to restore deleted objects in
their entirety while AD DS is running.
All domains that are subsequently added to the forest will operate at
the Windows Server 2008 R2 domain functional level by default.
If you plan to include only domain controllers that run Windows
Server 2008 R2 in the entire forest, you might choose this forest
functional level for administrative convenience. If you do, you will
never have to raise the domain functional level for each domain that
you create in the forest.
W2K8R2
W2012
W2012R2
Windows Server
2012
All of the features that are available at the Windows Server 2008 R2
forest functional level, but no additional features.
W2012
W2012R2
CAUTION
Raising the domain and forest functional levels to Windows Server 2008 is a
nonreversible task and prohibits the addition of Windows 2003-based domain
controllers to the environment. Any existing Windows 2003-based domain
controllers in the environment will no longer function. Before raising
functional levels to take advantage of advanced Windows Server 2008 or
higher features, ensure that you will never need to install domain controllers
running Windows 2003 in your environment.
NOTICE
Varian security scripts work on all functional levels supported by Windows
Server 2012 R2 and 2016 because no features specific to certain functional
levels are used to create the Varian Active Directory objects.
3.3 New Security Features
Some of the new security features implemented in ARIA v16.x are defined and described below for technical
reference.
3.3.1 Database Access and Application Roles
In ARIA v16.x, application access to the database is managed using Application Roles, instead of an
application specific login used in previous versions.
An application role is a database principal that enables an application to run with its own, user-like
permissions. Application roles can be used to enable access to specific data to only those users who connect
through a particular application, thus preventing users from accessing data with unauthorized applications.
The application accesses data using the respective application role permissions, irrespective of who is
connected to the database. This provides a level of security for the data and other database objects.
Connection and authorization steps:

1. Domain user logs into Varian applications using AD credentials.
2. Varian application calls Shared Framework to request App Role
3. Shared Framework connects to MS SQL server, using the applications’ AD credentials, to get App Role.
4. Attributed App Role is used by the application to connect to a specific database to read and/or modify data.
Figure 3: DB Connection Using App Role
The domain users running the client applications are still authorized in the initial MS SQL Server connection,
and for that reason, the Varian Application Users group has to exist in MS SQL as a server instance Login. The
users and computers in this group can connect to the server instance in MS SQL, but do not have access to
the databases.
The server instance login for the Varian Application Users or other group is created by the Varian Database
installer, which prompts the user for a domain group.

Figure 4: MS SQL Login for Varian Application Users group
3.3.2 Specific Requirements for Services
Some Varian client applications may make use of services to perform specific tasks. These services can be
web services, DICOM Services or DCF calculation agents.
Web services are installed and run in Internet Information Services (IIS) in the web server (Web Server),
normally the same machine as the Varian System Server. An example of such web services is the RT Service
used by RT Summary application.
All these services require read and write access to images and beam data stored in the VA_DATA$ and DCF$
shares, as well as access to the Varian database.
Since no application specific, local accounts exist in ARIA v16.x, all services should run under the NETWORK
SERVICE account, including web services in IIS, Daemon services and DCF services. This is set by default
during installation and DICOM service instance creation as displayed in Figure 5 for Windows Services
(DICOM; DCF), and Figure 7 for Web Services.

Figure 5: Default Log On account configuration for services (password is prefilled)
To guarantee the services have the necessary access to all required resources, it is required that all machines
running services be added to the Varian Computers group, or directly to the Varian Application Users group.
This group has the necessary permissions to access all required resources as pictured in Figure 1: AD
Security Guideline.
Account <domain><machinename>$ should be added to a group using the security scripts as described
in Chapter 5, section 5.2 or manually as described in section 5.2 of the same chapter.
As an alternative, the services can also run under one or several domain user accounts. In such configuration
the customer is responsible to manage all the necessary accounts and passwords. Applying the same
permissions concept described above to this case means that domain accounts must be added to the Varian
Application Users group, or a sub-group.
Figure 6: Internet Information Services (IIS) Manager

To verify or change the web service Log On account, designated Identity go to the machine where Shared
Framework Server component was installed and open Internet Information Services (IIS) Manager. Click on
Application Pools (Figure 6), select one of application pools and click Advanced Settings… on the right side
to display the settings in Figure 7, including the Identity which corresponds to the account under with the web
services run.
Figure 7: Default Log On account configuration for web services
3.3.2.1 Access to Web Services from Outside The Domain
The current authentication concept based on Active Directory credentials automatically denies access to
domain based Varian resources from users or computers outside the Domain. This is the case of services
running in the treatment environment behind MICAP firewall, like the Queue.
To overcome this barrier the Platform Server Gateway Proxy service was implemented in IIS, which provides a
gateway for services from authorized IP addresses to connect to the Shared Framework Server component.
To allow applications running behind MICAP firewall to communicate with Web Services, follow the
configuration steps below, as described in SIM-SF-160.
1. Open Internet Information Services (IIS) Manager > Sites >PlatformServer and select GatewayProxy.
2. In the GatewayProxy Home page double-click on IP Address and Domain Restrictions
3. In the Actions pane click Add Allow Entry…
4. In the Add Allow Restriction Rule box that pops up, enter the IP address of the device from which the
request will originate. For a given MICAP environment this will be the IP address of the Juniper firewall.
3.3.3 SSL Communication AND Certificates
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols
designed to provide communications security over a computer network. They use digital certificates and hence
asymmetric cryptography to authenticate the counterparty with whom they are communicating, and to

negotiate a symmetric session key. This session key is then used to encrypt data flowing between the parties.
This allows for data/message confidentiality and message authentication codes for message integrity and as a
by-product, message authentication.
A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows
others (relying parties) to rely upon signatures or on assertions made by the private key that corresponds to
the certified public key.
In the ARIA environment, self-signed certificates are emitted by the servers and deployed to all ARIA
workstations. These certificates attest the servers’ identity and allow for use of SSL-based encryption in end-
to-end communication between servers and client workstations.
In a single server environment, only one server certificate is required. This certificate is created by the
PreReqMaster (SVRCORE) when it is executed on the server. Keystone (RSD) later deploys and installs the
server certificate in all client workstations.
Additional instructions for manual certificate installation are described in SIM-SF-160.
Figure 8: Server Certificates installed on client workstation (run:certmgr.msc)
In a multi-server environment, several server certificates are required; for the Database server, Shared
Framework Server (Web Server) and Aura Server respectively. The different server certificates need to be
shared across all servers and to client workstations.
Each server certificate is attached to the services running in the respective machine. This procedure is
performed automatically during installation, but it can be verified as described below.
Figure 9: IIS Server Certificates

In the case of the Web Server, the certificate bindings can be verified in IIS by clicking Server Certificates in
Server Home (Figure 9). Specific web-site certificate binding can be verified by selecting a site (e.g.:
PlatformServer), clicking on Bindings… on the right side and finally clicking on the https binding, revealing
the Varian SSL certificate used by that site as displayed in Figure 10.
Figure 10: Site SSL Certificate Binding
MS SQL Server is also configured to use a specific certificate. This can be verified in SQL Server
Configuration Manager > SQL Server Network Configuration, right-mouse click on Protocols for
MSSQLSERVER > Properties (Figure 11). The Certificate tab reveals the Varian SSL certificate used for DB
connections as displayed in Figure 12.
Figure 11: SQL Server Configuration Manager

Figure 12: MS SQL Server Certificate Binding
3.3.4 Firewall Configuration
It is recommended to enable the Windows Firewall on Varian servers and client workstations.
Software applications will automatically create the necessary firewall rules during the installation process. The
Daemon configuration utility will also create firewall rules as services are configured.
Firewall rules created by Varian software have names starting with Varian.
Figure 13: Varian Firewall Rules

3.3.5 Access to Domain Resources from Non-Domain Computers
In ARIA v16.x all computers running ARIA RTM applications and services are required to be part of the domain
as defined in Chapter 3 section 3.2 Active Directory Environment Design Guidelines. Other Varian or third-
party devices, like treatment devices, gating devices or simulation devices, run in non-domain computers or
behind MICAP firewalls.
Some of these devices still require access to ARIA resources like file shares, which are hosted in domain
computers. For these particular cases, the required (domain side) file shares can be mounted on the non-
domain machines using specific domain accounts with very limited permissions as defined in Table Users in
Chapter 3 section 3.2.1.
Examples:
• DICOM Stream Service requires access to VA_TRANSFER share for file mode treatment.
• RPM and RGSC require access to VA_GATING share to exchange motion management files.
• PeerSync requires access to VA_TRANSFER to synchronize treatment files.

4 Active Directory Environment Security Reference
4.1 Security Requirements
The security requirements for installation and runtime need to be distinguished. The installation of applications
requires more rights than the everyday use of these applications.
4.1.1 Security Requirements for Installation
• Local Administrator rights on all Varian Servers
• Local Administrator rights on all Clients where ARIA is to be installed.
A domain administrator typically has both of the above rights and is therefore the easiest way to perform an
installation. Organizations with stringent rules or complex hierarchies of administration are likely unable to offer
Domain Administrator rights.
Being member of the group ‘Varian Administrators’ is the alternative. Members of this group can perform
installations and upgrades.
The inclusion of Full Control permissions for the Varian Administrators group in all Varian resources is not
required for runtime, nonetheless it aims to increase the serviceability of the system by Varian personnel.
4.1.2 Security Requirements for Runtime
In order to run any ARIA application, one must be a member of the Varian Application Users group.
4.2 Server Reference
4.2.1 Directories Used by Varian Applications
TABLE 7: DIRECTORIES USED BY VARIAN APPLICATIONS
NAME DESCRIPTION EXAMPLE
SHARED?
HIDDEN?
<VMSOS_DATA_ROOT> <VMSOS_DATA_ROOT> is the
root directory for configuration
data.
D:VMSOS no no
<VMSOS_PROGRAM_ROOT> <VMSOS_PROGRAM _ROOT>
is the root directory for all
applications.
C:Program
FilesVarian or
C:Program Files
(x86)Varian
no no
<VARIAN_FILE_DATA >
(VA_DATA)
Filedata directory for images and
dose files that require large
storage capacity.
D:VarianData yes yes
<VA_TRANSFER> Transfer directory for file data
transfer but not for persistent
data.
D:VarianTransfer yes no
<DCF> Beam data share D:VMSOSDCF yes yes
<VA_GATING> Varian Gating share D:VarianGating yes yes

4.2.2 <VMSOS_DATA_ROOT> Directory
The <VMSOS_DATA_ROOT> directory (e.g. D:VMSOS) includes all the local configuration data for Varian
Applications, including user preferences and SF settings, as well as local log and temporary files.
4.2.2.1 Folder Permissions
NOTICE
The permissions set on the <VMSOS_DATA_ROOT> directory are set
automatically by the installation of SF Server.
Directory <VMSOS_DATA_ROOT> e.g. D:VMSOS
TABLE 8: USERS AND GROUPS ON <VMSOS_DATA_ROOT> DIRECTORY
USERS / GROUPS PERMISSION
Domain Admins Full Control
Administrators Full Control
System Full Control
Users Read & Write
TABLE 9: DETAILED PERMISSIONS ON <VMSOS_DATA_ROOT> DIRECTORY
GROUP USERS
Permission Allow Deny
Full Control  
Modify  
Read & Execute  
List Folders Contents  
Read  
Write  
Special permissions  
Advanced settings:
Click Disable inheritance if enabled.
 Replace all child object permission entries with inheritable permission entries
from this object
Table 8: Users and groups on <VMSOS_DATA_ROOT> DIRECTORY
NOTICE
If permissions are changed manually and the DCF share resides in the
<VMSOS_DATA_ROOT>, make sure the DCF share has the correct settings as
described in section 4.2.6.

4.2.3 <VMSOS_PROGRAM_ROOT> Directory
NOTICE
The permissions set on the <VMSOS_PROGRAM_ROOT> directory are Windows
default permissions and are listed as reference. No manual correction is
required.
Directory <VMSOS_PROGRAM_ROOT> e.g. C:Program Files (x86)Varian
TABLE 10: USERS AND GROUPS ON <VMSOS_PROGRAM_ROOT> DIRECTORY
ALL APPLICATION PACKAGES Read & execute
CREATOR OWNER Full Control (Subfolders and files)
SYSTEM Full Control (Subfolders and files)
Authenticated Users Read & execute
TrustedInstaller Full Control (Subfolders and files)
TABLE 11: DETAILED PERMISSIONS ON <VMSOS_PROGRAM_ROOT> DIRECTORY
GROUP AUTHENTICATED USERS
Modify  
Read  
Write  
Advanced settings
 Replace all child object permission entries with inheritable permission entries
from this object
Table 10: Users and groups on <VMSOS_PROGRAM_ROOT> directory

4.2.4 <VARIAN_FILE_DATA> Directory
The <VARIAN_FILE_DATA> directory, and associated VA_DATA$ share, are the main repositories for RT
objects stored persistently by the ARIA system, such as multi-modality images, treatment records, RT dose
objects, RT structure sets, etc.
NOTICE
Verify the folder permissions and reset to the permissions described in this
guide if they are different.
Directory:<VARIAN_FILE_DATA> e.g. D:VarianData
TABLE 12: USERS AND GROUPS ON <VARIAN_FILE_DATA> DIRECTORY
SYSTEM Full Control
Varian Administrators Full Control
Varian Application Users Modify
NETWORK SERVICE Modify
TABLE 13: DETAILED PERMISSIONS ON <VARIAN_FILE_DATA> DIRECTORY
USERS & GROUPS
VARIAN APPLICATION USERS /
NETWORK SERVICE
PERMISSION ALLOW DENY
Modify  
Read  
Write  
Advanced settings
from this object
Table 12: Users and groups on <VARIAN_FILE_DATA> directory

4.2.4.2 Share Permissions on VA_DATA$
NOTICE
Verify the share permissions and reset to the permissions described in this
Share VA_DATA$ e.g. D:VarianData
TABLE 14: USERS AND GROUPS ON <VARIAN_FILE_DATA> SHARE
Varian Applications Users Change
NETWORK SERVICE Change
TABLE 15: DETAILED PERMISSIONS ON <VARIAN_FILE_DATA> SHARE
USERS & GROUPS VARIAN APPLICATION USERS / NETWORK SERVICE
Change  
Read  
4.2.5 <VA_TRANSFER> Directory
The VA_TRANSFER share is not a hidden share and shall be used to transfer any file data between clients.
The VA_TRANSFER share is less restrictive than the VA_DATA$ structure and shall not be used for any
persistent data.
To avoid unintended deletion of persistent data in the <VARIAN_DATA_ROOT> share, the <VA_TRANSFER>
share is offered for importing and exporting data. In addition, users shall be able to find this share with
reasonable effort and therefore it shall not be a hidden share. The transfer share might be created next to the
<VARIAN_DATA_ROOT> location on the image server.

The following first-level directories are defined under the transfer directory. Not all of them may be present:
TABLE 16: DETAILED VA_TRANSFER DIRECTORY DESCRIPTION
DIRECTORY CONTENT EXAMPLE
<VA_TRANSFER><ProductID> Product specific transfer data (E.g.
TDS, TMS, 4DITC).
D:VarianTransferRTChart
D:VarianTransferTDS
<VA_TRANSFER>DICOM DICOM specific transfer data (E.g.
RT Plans, Treatment Records,
Images etc.)
D:VarianTransferDICOM
DEFAULTS FOR TRUEBEAM USING PEERSYNC:
<VA_TRANSFER>TDSInput Copied to all TDSInput D:VarianTransferTDSInput
<VA_TRANSFER>TDSSNxxxx
Output
Copied from the specific TDSOutput
(SNxxxx is the hardware specific
serial number)
D:VarianTransferTDSSN1234
Output
NOTICE
Directory <VA_TRANSFER> e.g. D:VarianTransfer
TABLE 17: USERS AND GROUPS ON <VA_TRANSFER> DIRECTORY
SYSTEM Full Control
LinacNetworkAccess Modify
VarianGating Modify
dicomdaemon (local user) Modify

TABLE 18: DETAILED PERMISSIONS ON VA_TRANSFER DIRECTORY
GROUP VARIAN APPLICATION USERS
Modify  
Read  
Write  
Advanced settings
from this object
Table 17: Users and groups on <VA_TRANSFER> directory
4.2.5.2 Share Permissions on VA_TRANSFER
NOTICE
Share <VA_TRANSFER> e.g. D:VarianTransfer
TABLE 19: USERS AND GROUPS ON <VA_TRANSFER> SHARE
Varian Application Users Change
LinacNetworkAccess Change
VarianGating Change
dicomedaemon (local user) Change

TABLE 20: DETAILED PERMISSIONS ON <VA_TRANSFER> SHARE
GROUP VARIAN APPLICATION USERS
Change  
Read  
4.2.6 Dose Calculation Framework <DCF> Directory
The Dose Calculation Framework requires a shared folder, which is created automatically during install
together with the necessary permissions. This folder is used to store beam data and should be accessible to
Eclipse, to DCF Calculation agents.
Eclipse accesses the DCF$ share to run calculations, read and modify Beam Data. Access is made through
‘Varian Application Users’ group, which requires full access (read and write) permission to the share.
Access from services to the necessary file shares is granted using the principles described in Chapter 3
Section 3.3.2 Specific Requirements for Services.
Full access rights (read, write) to VA_DATA$ and DCF$ shares, are also required by the Web Server running
TPS Services. Whether they reside on different computers or on one single host, permissions shall be granted
to the appropriate computer account.
Access should be granted to the network shares (VA_DATA$ share and DCF$) for the Web Server machine
under which TPS Services run, as shown in Figure 14.
Web Server
Plan
Service
VA_DATA$
VOS
Data
DCF$
Beam
Data
Full access
Full access
Figure 14: DCF Network Schema
NOTICE
The permissions on the <DCF> directory are set automatically by the
installation of Varian DCF Core Server.
Directory: <DCF> e.g. D:VMSOSDCF

TABLE 21: USERS AND GROUPS ON <DCF> DIRECTORY
SYSTEM Full Control
NETWORK SERVICE Modify
TABLE 22: ETAILED PERMISSIONS ON <DCF> DIRECTORY
USERS & GROUPS
VARIAN APPLICATION
USERS
Modify  
Read  
Write  
Advanced settings
from this object
Table 21: Users and groups on <DCF> directory
4.2.6.2 Share Permissions on DCF$
NOTICE
The permissions on the <DCF> share are set automatically by the installation
of Varian DCF Core Server.
Share: <DCF>e.g. D:VMSOSDCF

TABLE 23: USERS AND GROUPS ON <DCF> SHARE
Varian Application Users Change
NETWORK SERVICE Change
DETAILED PERMISSIONS ON <DCF> SHARE
USERS & GROUPS VARIAN APPLICATION USERS
Change  
Read  
Table 24: Detailed permissions on <DCF> share
4.2.7 <VA_GATING> Directory
The <VA_GATING> directory and associated share are a repository for motion management files and
supporting database for the RPM and RGSC systems.
NOTICE
Directory: <VA_GATING> e.g. D:VarianGating
TABLE 25: USERS AND GROUPS ON <VA_GATING> DIRECTORY
VarianGating Modify

TABLE 26: DETAILED PERMISSIONS ON <VA_GATING> DIRECTORY
GROUP / USER VARIANGATING
PERMISSION ALLOW DENY
Change  
Read  
Advanced settings
from this object
Table 25: Users and groups on <VA_GATING> directory
4.2.7.2 Share Permissions on VA_GATING$
NOTICE
Share: VA_GATING $ e.g. D:VarianGating
TABLE 27: USERS AND GROUPS ON < VA_GATING> SHARE
VarianGating Change
TABLE 28: DETAILED PERMISSIONS ON < VA_GATING > SHARE
GROUP / USER VARIANGATING
Change  
Read  

4.3 Client Reference
4.3.1 <VMSOS_DATA_ROOT> Directory
NOTICE
The permissions set on the <VMSOS_DATA_ROOT> directory are set
automatically by the installation of SF Client.
Directory <VMSOS_DATA_ROOT> e.g. D:VMSOS
TABLE 29: USERS AND GROUPS ON <VMSOS_DATA_ROOT> DIRECTORY
System Full Control
Users Read & Write
The Users group mentioned above is the local Users group, not the Domain Users group.
TABLE 30: DETAILED PERMISSIONS ON <VMSOS_DATA_ROOT> DIRECTORY
GROUP USERS
Modify  
Read  
Write  
Advanced settings.
from this object.
Table 29: Users and groups on <VMSOS_DATA_ROOT> directory

4.3.2 <VMSOS_PROGRAM_ROOT> Directory
NOTICE
The permissions set on the <VMSOS_PROGRAM_ROOT> directory are
Windows default permissions and are listed as reference. No manual
correction is required.
Directory <VMSOS_PROGRAM_ROOT> e.g. C:Program FilesVarian
TABLE 31: USERS AND GROUPS ON <VMSOS_PROGRAM_ROOT> DIRECTORY
ALL APPLICATION PACKAGES Read & execute
CREATOR OWNER Full Control (Subfolders and files)
SYSTEM Full Control (Subfolders and files)
Authenticated Users Read and Execute
TrustedInstaller Full Control (Subfolders and files)
TABLE 32: DETAILED PERMISSIONS ON <VMSOS_PROGRAM_ROOT> DIRECTORY
GROUP AUTHENTICATED USERS
Modify  
Read  
Write  
Advanced settings
 Replace all child object permission entries with inheritable permission entries
from this object
Table 31: Users and groups on <VMSOS_PROGRAM_ROOT> directory

5 Implementing Security
5.1 Implementation
To implement the required security configuration, scripts are provided which create users, groups, and OUs. In
an Active Directory, user and group management requires domain administrator rights. Share and file
permissions are set automatically on <VMSOS_PROGRAM_ROOT> and the <VARIAN_FILE_DATA> directory
while installing SF and Varian System Server, respectively.
NOTICE
OSP installer version 2.7.x and earlier creates a share on
<VMSOS_PROGRAM_ROOT> directory with full permissions to everyone. Also
the file permissions are set to full permissions to everyone. This is corrected
in OSP 3.x. Please recreate the default permissions according to the
description in Chapter 4.3.7 by inheriting the parent folder permissions.
5.1.1 Remove Unused Share
Verify if the following share exists and if true delete it.
Share on folder {C:}Program FilesVarian
If directory {C:}Program FilesVarian created by the OSP installer is shared, the share can be removed since it
is not needed any more.
5.1.2 Migrate OSP Users
In ARIA v16.x, OSP users cease to exist, and are replaced with AD users. User rights previously assigned to
OSP users need to be transferred to the corresponding AD users, manually or using the ‘Users Mapping Tool’
provided with Shared Framework (SF).
The user mapping process should be performed and validated prior to the system upgrade, resulting in an
output file necessary at the time of SF upgrade.
Please refer to SIM-SF-160 for details on the user mapping process.
5.1.3 Checklist for Server Configuration
Before starting the security implementation, the objects in the following checklist should be known:
TABLE 33: SECURITY INFORMATION
NR ITEM DEFAULT VALUE CUSTOM VALUE
Domain Name e.g. Oncology
Varian Server(s) e.g. VARDBSR01
Server Language English
Groups to be created
Varian Administrators (Domain Resource
Group)
Varian Application Users (Domain
Resource Group)

TABLE 33: SECURITY INFORMATION
NR ITEM DEFAULT VALUE CUSTOM VALUE
Varian Users (Domain User Group)
Varian Computers (Domain User Group)
Domain users to be created
Varian Service
Installer
Trainer
VarianGating
SsisUser *(AURA)
ReportsUser *(AURA)
Additional users and groups may be added to the above as required.
5.2 Implementation Using Scripts
The user and group objects described in Chapter 2 section 2.2 Active Directory Environment Design
Guidelines can be created using the Varian Security Script, which is delivered in [1] P1037893xxx System
Server Media (Backup and Security) - SecurityScripts.
This tool creates the needed users and groups and also assigns the users to the correct groups.
NOTICE The scripts do not modify any file or share permissions.
Execute the script using a Domain Admin account. Run the Varian.SecurityScripts.vbs script from an elevated
command prompt. Follow the instructions provided by the tool as described below:
Figure 15: Initial window. Click Yes
The tool will automatically detect a local Domain (Figure 16). Correct the Domain name if necessary.

Figure 16: Detected Domain
The tool will query about the local environment (Figure 17). It will ask if the following dedicated machines are
used, and the respective hostnames:
• IIS Server – machine running Web Services, normally the SF Server.
• DCF Server – machine where DCF Core component is installed.
• DICOM Server – machine running Daemon Services and/or DICOM Services.
• FAS Servers – machines used to run dose calculation jobs within DCF.
Figure 17: Environment specifications – IIS Server
Figure 18: Environment specifications – IIS Server Hostname
Figure 19: Environment specifications - – DCF Server Hostname

Figure 20: Environment specifications - DICOM Server Hostname
Figure 21: Environment specifications – Number of FAS Servers
Figure 22: Environment specifications - FAS Servers hostnames
Figure 23: Environment specifications - Domain Controller hostname

Figure 24: Security Scripts - Output Summary
The SecurityScripts tool will finalize by displaying a Summary (Figure 24) indicating all performed actions,
and by opening the Active Directory Users and Computers management tool (Figure 25).
Figure 25: Active Directory Users and Computers
Review the script's output log file to verify its successful execution. By default this log file is called
SecurityConfigurationt.log and is written to the current directory. If necessary open it and verify if all the
security objects are created successfully.

5.3 Manual Security Configuration for Windows
The following section is a short instruction on how to manually create organizational units, users and group
objects.
All security settings can be done manually using the operating system front end. This includes user and group
creation and as well file and share permission changes.
5.3.1 Manually Creating an AD Organizational Unit (OU)
NOTICE Organizational Units are Active Directory containers to group objects.
1. Create an Organizational Unit called Varian according to the steps below.
2. Logon with Domain (Local) Administrator Rights
3. Start User manager: Start > Run > Open: dsa.msc > Enter
4. Select the domain object and click on Action > New > Organizational Unit
5. Enter a New Organizational Unit Name, for example: Varian OK
5.3.2 Manually Creating Users
Create all users defined in Chapter 2.2.2, according to the steps below.
1. Logon
a. Windows server domain: Logon with Domain (Local) Administrator Rights
2. Start User Manager
a. Windows server domain: Start > Run > Open: dsa.msc > Enter.
3. Create User object
a. Windows server domain:
b. Select the appropriate organizational unit and click on Action > New > User.
4. New User
• First name: Thomas
• Initials: TH
• Last Name: Hill
• Full Name: Thomas TH. Hill
• User logon name: thill
b. Click Next
• Password: ********
• Confirm Password: ********
c. Options •  Password never expires
(for background service logins)
(set other options according to local IT policy)

5. Click Next and then click Finish.
6. Double click on the created object and verify the data on tab General to be correct.
7. Repeat steps 3 and 4 for every new user to be created.
8. Click Close after adding all defined Users.
5.3.3 Manually Creating Groups
Create all groups defined in Chapter 4, section 3.2 according to the steps below.
1. Logon
a. Windows server domain: Start > Run > Open: dsa.msc then click Enter
3. Create Group object
b. Select the appropriate organizational unit and click on Action > New > Group
New Global/(Local) Group
• Group Name: e.g. Varian Users; see chapter 2 section 2, Active Directory Environment Design
Guidelines
• Group scope:  Global /  Domain Local
• Group type:  Security
b. Double click on the created object:
• Description: e.g. Members can run Varian Applications see chapter 2 section 2, Active
Directory Environment Design Guidelines
• Members: Add enter name, for example therapist then click OK
5. Repeat steps 3 and 4 to create all Groups.
5.3.4 Manually Add Users or Computers to Groups
Create all groups defined in Chapter 4, section 3.2 according to the steps below.
1. Logon
• Windows server domain: Start > Run > Open: dsa.msc then click Enter
3. Add User or computer to a Group
• Expand the desired category folder: Computers / Users
• Right click over the user or computer and select Add to a group…
4. Select Group
• Windows server domain:
• Enter the object names to select: e.g. Varian Users then click Enter

• Double click over the group name
5. Repeat Step 3 and 4 to add all users and computers to Groups.
5.3.5 Manually Setting Permissions on Directories
Set the file permissions defined in Chapter 4, sections 3.2, 3.2.7 according to the steps below.
1. Logon
2. Start Windows Explorer: Start > Run > Open: Explorer then click Enter
3. Browse to the corresponding directory, e.g.: C:Program FilesVarian
4. Right click on the directory, e.g.: Varian
5. Click on Properties
6. In the Properties window click on the Security tab
7. Add a user or a group
a. Click on ADD to add Users/Groups
8. Choose permission
a. Choose a User or a Group e.g. Administrators
b. Choose the type of access e.g. Read
9. Access Control Settings
10. The permissions for all added Users/Groups have to be applied to all subfolders.
11. Click Disable inheritance if enabled.
from this object
12. Click on Apply
13. Directory Permissions
14. Repeat steps 8 to 9 for all other Users/Groups in the corresponding directory list
15. Remove all other Users/Groups not listed in the corresponding directory
16. Click OK
17. Click on Yes to replace permissions
5.3.6 Manually Setting Permissions on Shares
Set the share permissions defined in Chapters 3.2.4.2 and 3.2.6.2 according to the steps below.
1. Logon
2. Windows server domain:
3. Logon with Domain (Local) Administrator Rights
a. Start Windows Explorer: Start > Run > Open explorer > Enter
4. Browse to the corresponding directory e.g. D: VarianData
5. Right click on the directory e.g. Data
6. Click on Properties
7. In the Properties window click on the Sharing tab

8. In the Sharing tab click on Permissions
9. Add a user or a group
10. Click on ADD to add Users/Groups
11. Choose permission
12. Choose a User or a Group e.g. Administrators
13. Choose the type of access e.g. Read
5.3.7 Reset File Permissions to Default Permissions
This section describes step by step to recover the default file permission on any folder.
1. Right click on the folder and select Properties
2. Change to the Security tab
3. In the lower part of the window click on Advanced button.
4. Click Enable inheritance.
5. Select the option Replace all permission entries on all child objects with entries shown here that
apply to child objects
6. Click OK
7. Click Yes to continue on the Security warning about overriding all child permissions.
8. After the permissions are applied to the child objects click OK to close the permission window.

6 Security Troubleshooting
The auditing tools described in this chapter can be used to troubleshoot problems caused by denied access to
Varian resources.
6.1 Auditing File and Folder Access
In order to track file and folder access on Windows Server 2012 it is necessary to enable file and folder
auditing and then identify the files and folders that are to be audited. Once correctly configured, the server
security logs will then contain information about attempts to access or otherwise manipulate the designated
files and folders.
1. To enable file and folder auditing for a single server, select Start > All Programs > Administrative Tools
> Local Security Policy (Run > secpol.msc). In the Local Security Policy tool, expand the Local
Policies branch of the tree and select Audit Policy.
Figure 26: Audit Policy
2. Double-click on the Audit Object Access item in the list to display the corresponding properties page and
choose whether successful, failed, or both types of access to files or folders may be audited.
3. Once file and folder access auditing has been enabled the next step is to configure which files and folders
are to be audited.
4. To configure auditing for a specific file or folder begin by right clicking on it in Windows Explorer and
selecting Properties. In the properties dialog, select the Security tab and click on Advanced. In the
Advanced Security Settings dialog select the Auditing tab.

Figure 27: Auditing entries
5. To add new users or groups whose access attempts to the select file or folder are to be audited click on the
Add...' button to access the Select User or Group dialog. Enter the names of groups or users to audit, or
Everyone to audit access attempts by all users.
6. Once configured, click on OK to dismiss current dialog and then Apply the new auditing settings in the
Auditing Entries dialog
Figure 28: Auditing Entry

From this point on, access attempts on the selected file or folder by the specified users and groups of the types
specified will be recorded in the server's security logs which may be accessed using the Events Viewer,
accessible from Computer Management.
6.2 Auditing NTLM Authentication
NTLM is an outdated authentication protocol used in Windows. Restrictions to NTLM usage can be set using
Security policies, however, such restrictions can prevent normal functioning of some applications.
The following three security policy settings can be used for auditing NTLM traffic. The settings are stored in the
following Group Policy Object (GPO) container: Computer ConfigurationPoliciesWindows SettingsSecurity
SettingsLocal PoliciesSecurity Options. They're called:
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
Network security: Restrict NTLM: Audit NTLM authentication in this domain
Network security: Restrict NTLM: Audit Incoming NTLM Traffic
The Restrict NTLM: Outgoing NTLM traffic to remote servers policy can be used for auditing NTLM
authentication traffic on all Windows 7 and Windows Server 2008 R2 / 2012 computers.
Figure 29: Audit NTLM
NTLM audit events are written to the following event log path: Applications and Services
LogsMicrosoftWindowsNTLMOperational. Note that this log isn't visible by default in the MMC Event Viewer
snap-in. To view this log, you must enable the Show Analytic and Debug Logs option in the Event Viewer's
View menu.
Whenever the NTLM protocol is used for authentication, an event shows up in the Windows log.

SIG-SS-16x-B.pdf

Recommended

Recommended

More Related Content

Similar to SIG-SS-16x-B.pdf

Similar to SIG-SS-16x-B.pdf (16)

Recently uploaded

Recently uploaded (20)

SIG-SS-16x-B.pdf