Many sub-infrastructure projects are by themselves are large projects (eg migrating file servers), and all components and dependencies need to be mapped out and documented, understood before migrating to the target operation model which is AWS in this case. Overview below of the components.
| Service Name | Description |
| 1. Active Directory | Active Directory (AD) is a directory service that Microsoft developed for Windows domain networks. It is included in most Windows Server operating systems as a set of process and services. AD is used as an authentication and authorization system to allow end user access to applications or services based on role. |
| 2. AWS Route 53 and external DNS | Route 53 is an external DNS network service provided by AWS which connects end-users to AWS infrastructure services and endpoints including EC2 instances, S3, ELBs. It is natively fault tolerant and can be configured to provide fail-over and recovery into different regions. As we migrate applications and AD into the cloud, we will be changing the DNS provisioning to allow access to AWS / AMS resources including application access. |
| 3. AWS DHCP | AWS Directory Service has a set of options for Dynamic Host Control Protocol which allows any instances in a particular VPC to connect to a particular domain and specified DNS servers to resolve domain names. DHCP is used in conjunction with Route 53 and DNS. As we migrate to AWS / AMS we will need to change DHCP settings by location and within AWS. |
| 4. Okta/SSO | Okta is used for SSO for end users and is integrated with AD. Currently Okta agents are on premise, connected to Okta SaaS and reading permissions from AD. Okta needs to be migrated into the new AWS AD domain as part of the AD migration. |
| 5. AWS Cloud Monitoring Nagios & Splunk | Native AWS monitoring including Cloud Trail, AWS Config, CloudWatch and VPC flows will be fed into Splunk via agents and forwarders from AWS. Splunk dashboards will be built to allow service delivery monitoring and environmental monitoring. OMS is not in scope. Nagios is an open-source (can be licensed under version XI); monitoring framework which can handle APM and Network Monitoring (NM). Nagios will monitor applications, application servers, and network performance in addition to flows (firewall logs). Nagios logs will feed into Splunk (integration between Nagios and Splunk is preferred but it can be implemented as a separate Nagios dashboard). |
| 6. Citrix Application Centre | Citrix App Center is a unified management console that allows admins to monitor and manage the entire virtualization environment from a single dashboard. There are many components to the CAC which will be deployed into AWS and Citrix Cloud; and over time likely decommissioned. |
| 7. O365 Exchange & AWS hosted Exchange Admin | Current O365 Exchange Admin server will be replaced by the same in AWS. Outlook email requires the admin server in order to provide an email service meaning that the AWS hosted Exchange admin server must connect to O365 and SMTP. |
| 8. Printers | Migrate printer controls and access to Cloud-IP network. AD Dependency. |
| 9. File Servers | Migrate 50 or so DFS, NAS to the cloud (file storage). AD Dependency. |
AD complexity as an Example
| Type of Objects | High Level Scope and Approach |
| User Accounts | 1. No user migration from any domain
2. Currently users are getting created in the Client domain. Work with Client to tweak the process to create in Client domain according to the feasibility of required tools and resources in place (However scripting efforts and changes will be done by the third-party agreed or will be aligned by Client) 3. Client will create third party policies to provide access to Client users. |
| Service Accounts | 1. Service accounts must be created in the Client domain if required and the services can be configured in resource forest.
2. If the service account needs to be in the resource forest in any case, that must be requested as part of the Service Request with AWS AMS. |
| Groups | 1. No group migration from any domain.
2. New groups need to be created to access the newly built application or servers in Client domain as per the process and add the required members. |
| GPO’s | 1. No migration needed from the legacy domains.
2. Modify the GPO’s as & when required as part of file server moves to the target to support the co-existence phase. 3. GPO’s will be avoided as much as possible as strategy is to move away from GPOs. 4. Clean-up the GPO’s at the end of the transformation programme once the resources have been migrated and dependency has been reduced. 5. No GPO’s in the resource forest. All security policies must be managed as per the build/AMS. |
| OU’s (operating units) | 1. No changes in the current OU structure
2. Clean-up the empty OU’s at end of the transformation programme once the resources has been migrated and dependency has been reduced. 3. OU’s on the AMS resource forest is completely managed by AMS |
| Workstation MDM | 1. No Workstation migration from any domain
2. Windows 10 new build machines will be added to the Azure AD as part of the in-flight project by third-party team as identified by Client 3. Azure AD will be used to manage mobile devices EMS – Azure AD and EMS is Out of scope for SI 4. The existing workstations will be replaced as part of the Windows 10 project 5. No new GPO requirements |
| Servers | 1. No AS IS migration
2. The server will be a new build in the Resource forest of AMS 3. Whatever is not feasible to run in the resource forest, will be built in AWS infrastructure under Client domain 4. Data/Configurations will be migrated application by application as per tranches 5. Application permissions must be assigned to meet the configuration of groups/users in the Client domain |
| DNS | 1. Conditional Forwarders will be created from On-premises to AMS resource forest and vice versa for the name resolutions.
2. Global search order list must be added in the clients/servers through GPO or baseline image policies 3. Existing integrated DNS will be AS IS 4. On-premises DNS servers as part of Client and Client domain will be decommissioned as and when the dependencies have been mitigated. 5. Route 53 has to be managed as a service by cloud team as part of cloud service |
| DHCP | 1. Native DHCP service will be used for the VPC subnets in the AWS
2. IP’s address of respective AMS resource domain controllers have to be assigned as primary and secondary DNS in the IP pool of VPC’s/subnet by cloud team as part of cloud service 3. DHCP will continue to be propagated by local DC’s up until all infrastructure is decommissioned. At some point all DC’s will be decommissioned at which point Client will need to initiate a project to stand-up a DHCP solution (hardware) that will manage the remaining infrastructure (outside of SI scope) 4. When the site is completely transformed to the AWS Infrastructure model the Extended DNS IP address has to be modified in the DHCP pool of on-premises |
| Printers | 1. New Printing solution-cloud based IP infrastructure for printing with appropriate hardware leased
2. No migration of existing print servers |
| Decommission | 1. Logical decommission and consolidation of on-premises Client/Client domain controllers as and when dependencies has been mitigated
2. Logical decommission and consolidation of on-premises Client/Client DNS as and when dependencies has been mitigated 3. Logical decommission of Client.Clientgroup.net child domain as soon as dependencies has been mitigated 4. Logical decommission and consolidation of DHCP Servers in on-premises as soon as dependencies has been mitigated a. Considering Client will need to initiate a project to stand-up a DHCP solution (hardware) that will manage the remaining infrastructure (outside of SI scope for now) 5. Remove the trust of Client.Clientgroup.net from Client.Clientgroup.net as soon as dependencies has been mitigated 6. Remove the trust of uk.Clientgroup.net from Client.Clientgroup.net as soon as dependencies has been mitigated |
Application and printer access obviously has an active dependency on AD, domain access, along with network and VPN client access (usually machines are installed with a VPN client granting AD GPO privileges to that user role and denying access to other domain based resources). If you move AD or change domains this will affect application and network access.
Each component will need a thorough analysis, rationale for the migration and an iterative but detailed approach to the migration. Dependency mapping, security, ensuring that no information is lost, locking down domains and access, and other architectural principles must be built in at the beginning.
Firms should never migrate both infrastructure and applications at the same. That will ensure a gigantic failure and denial of application access and usage.
===END