Support and FAQ
Installation of DSEvolution on a domain controller has the following pre-requisites
- Active Directory Domain controller at least Windows 2003 (x64), recommended 2008 R2
- .net 4 client side extensions (x64)
- C++ 2010 redistributable components (x64)
- Domain Admin credentials
DSEvolution is a mature system having evolved through many versions since 2002. Each release has enhanced the stability of the system and added new features and functionality welcomed by clients. Mor information aboutn the changes over time can be found here:
When dealing with the Active Directory, it is important to distinguish between “Physical” and “Logical” components of the architecture.
The Physical is that part of the Architecture that offers availability of directory services and replication of directory data. The Physical is usually completed successfully enough because failures tend to be very visible, for example:
- Users can’t log on properly
- Email delivery fails
The Logical is that part of the Architecture that allows the Active Directory to Increase Security and ROI of the whole Windows Infrastructure. The “Logical” commonly receives less attention (time and cost constraints, specialist resource availability etc) than the Physical, but its lack of completion goes un-noticed until a critical security, DR or Audit event occurs. Some of the indicators of an incomplete Logical phase (an “under-optimised” Active Directory) are:
- Limited implementation of strong security such as role-based authority
- Incomplete change control enforcement
- Compromised security audit trails
Optimisation is the process of upgrading the Logical architecture of an Active Directory implementation to increase its security and ROI. Physical architecture is rarely affected. In all cases this optimisation requires that existing structure within the directory database is replaced by new.
The Traditional approach is to generate the new structures by iterative re-developments of the existing architecture, often utilising specialist consultancy. This approach is time consuming, expensive and intrusive. The process itself has deterred many organisations from optimisation. A new alternative is now available using the DSEvolve Exert System which quickly, easily and cost effectively optimises the Active Directory with little or no disruption to the business
Hierarchal Authority is a description of the way that IT Administrative power is organised within an organisation. The aim is to ensure that those in possession of greater authority delegate reduced authority to those below them in such a way that individuals of ‘lesser authorities’ cannot interfere with the management of their peers.
Consider the way that operational authority is structured in most organisations:
Senior management layer:
At the Apex of any organisational hierarchy are the very few individuals that have broad and far reaching powers. These individuals should have a deeper understanding of the organisation and be fully aware of the effects that wielding their powers will have. Senior managers will usually have a broad remit of responsibility.
For example: The Finance Director takes responsibility for all aspect of financial management, and has the power to transfer any amount of money from the company accounts to pay the company bills. This authority can be delegated as the Finance Director sees fit. This breakdown and delineation of actual power is called “Role-based Authority”.
The Middle Management Layer:
The middle managers are employed by the senior management to take responsibility for a particular aspect of the running of the company. They receive their (delegated) authority from their senior manager.
For example: In the finance department, the Director hires three managers. Each will take responsibility for one of the key functions: Invoicing, Purchasing, and Reporting. To each is delegated the power required to discharge their role, for example the purchasing manager can sign of payments of up to £5000. This is another role within the hierarchy.
Critically only the Finance Director can hire & fire individuals within the Finance Department, or delegate authority to an individual in the Finance Department. The Sales Director, who is a peer director, is not authorised to perform either of these tasks within the Finance Department.
The Workers are those employed by the middle managers to perform certain tasks. Typically they are only given enough authority to enable them to perform their designated tasks.
For example: In the finance department, the purchasing manger Hires ten purchasing clerks who are responsible for tabulating received invoices and preparing them for payment. But they must still get the signature of the Manager (or the Director if the Manager is away) to enact the payment. Another role at the next layer of the hierarchy.
Critically only the Purchasing Manager (or his line manager – the Finance Director) can hire & fire individuals within the Purchasing Department, or delegate authority to an individual in the Purchasing Department. The Invoicing Manager, who is a peer manager, is not authorised to perform either of these tasks within the Purchasing Department.
The following diagram is a representation of how a network Authority Structure may look within a company with International offices:
- “Enterprise Admin” can create a “Domain Admin”
- Only an “Enterprise Admin” or ”Domain Admin” can create a “Paris Admin” or “London Admin”
- Only an “Enterprise Admin” or “Domain Admin” or ”London Admin” can create a “London Server Admin”
Note: A “Paris Admin” cannot perform any of these tasks
- The Security Administrators have their own authority chain that is ‘external’ to the main authority stream – this is an operational over-ride facility.
Privilege Elevation is the goal of any many attacks against computer systems. The aim is to find a way of obtaining authority greater than was originally assigned, for example:
- A normal user trying to gain Admin powers over his workstation
- An email administrator trying to get control over the SQL databases
- A user administrator trying to reset a domain administrator’s password
Role separation is the principle that administrative roles should be separated. For example: London User Admins, Birmingham User Admins. Administrative authorities, and their responsibilities, should be assigned to different network user credentials. It may be that one individual has several different sets of credentials to cover all aspects of their duties.
- An administrator would be able to perform most of his duties using normal user credentials – sending email, writing documents, and so on. But when they need to, say, add a new user, they would log on with different credentials – credentials that would carry sufficient privileges to carry out this task. When the task has been completed they would log out and return to their normal duties using normal credentials.
- The authority of a Domain Admin account is not required for 98% of normal operational work. This authority is very high level Administrator authority and should not be invoked (logged on with…) unless it is needed. Though sometimes impractical, it is better practice for the administrator who is assigned a Domain Admin account to also be assigned a lesser admin account with which to perform tasks that do not need such very high level Administrator authority as Domain Admins.
Correct implementation of Role Separation minimises the potential of administrative mistakes and lessens the chance of a third party gaining access to system resources if the administrator is not present at the terminal upon which they were working.
Although very simple, Role Separation is often overlooked as a basic security measure.