Samba4 Active Directory in action in a Commercial Bank in India
Sometime back the an institution promoted by Central Bank in India had conducted workshop on "Road for adoption of Open Source Software in Banks", where we had presented a case study on the extent of Open Source Adaption in one of the Premier Scheduled Commercial Bank Headquartered in South India. The bank has a staff strength of about 7500, operating about 800 branches across the country. I thought I should present this specific case study here through this article. Probably this will set the standards for adoption of Open Source technology for different critical and non-critical functions.The bank, for core banking system, has been operating the Proprietary Software for long and they continue to upgrade the same for their core operations. However the bank, during the year 2003, for many applications like HR Leave Management, Customer Grievance Portals, IT Support Management, Bills Collections, internal chat, file sharing etc., that are classified as non-critical and that do not get exposed customer or become a part of the Bank’s Core operations, considered the LAMP stack, customized the many open source products to suit their need. As those applications / platforms grew critical, the bank started seeking external support. It is at this juncture Team eXzaTech got involved with many different projects within Bank.One such project was to implement Active Directory for bringing in Centralized Authentication and Authorization solution to many applications, systems across the organization. With Central Bank making the Central Authentication mandatory for all applications including the critical and non-critical applications and having audit trail intact for a given period of time, implementing LDAP or Active Directory was becoming mandatory. While the architecture complexities and roll out challenges across the bank remained a primary challenge, licensing metrics, its compliance, compatibility with old aging operating systems used in Bank were other important decision making factors. Considering one important factor - compatibility with old & aging systems and applications had made it clear that the Active Directory is the way to go. However, prohibitive costs & licensing complexities of proprietary solutions like Microsoft Active Directory were making the bank to think and consider an alternative solution to Microsoft Active Directory that is fully compatible with all platforms, applications, and confirms to the same standards as that of Microsoft Active Directory and Linux Samba came in handy to achieve the goal.
Study the environment, come up with deployment architecture & plan
Providing the platform
Setting up the Active Directory, DNS and few basic policies.
Administration & User Self Service Portals
Log collection and storage for audit, traceability and lay the foundation for PIM and PAM.
Support & Services under Service Level Agreements over a period of time & user training.
The whole exercise of deployment was divided into 8 phases starting from "Understanding the environment, application needs prior to Active Directory roll out" to "Developing Administrator / user specific documentation specific to the Bank" to "Providing post implementation support for a defined period of time under a Service Level Agreement".
The schematic representation of bank's network is shown below.
Considering the workload, number of applications / devices to integrate, network priorities, location of AD admin group, it was decided that we create 4 Domain Controllers with PDC emulator is the DR Center at Head Office (HO). This decision was taken considering the fact AD roll out decision was taken at HO and primary AD administration group was also commissioned within HO-IT team.
The PDC emulator was configured on a physical server while one of the additional domain controller at DR-HO was created on a Virtual Machine hosted on KVM / oVirt.
Similarly, in order to balance the workload, two additional domain controllers were added at bank's Data Center (DC) of which one is a physical server and the other one is a Virtual Machine hosted on KVM /oVirt.
Operating System : CentOS 7.3 - Build 1611
Samba Version : 4.6.5
DNS - BIND9 - Version 9.9.4
While the directory data replication happens in real-time between all 4 Domain Controllers, the GPO create / change / update is restricted to be done on PDC emulator, setup at the DR-HO, and synchronized with other additional domain controllers at every 30 minutes using "rsync". The "rsync" script runs as a "cronjob" every 30 minutes on all additional domain controllers.
Apart from standard setup, in order to ensure that all old applications are allowed to integrate with Samba-AD, LDAP was configured not to insist on strong authentication by adding line "ldap server require strong authentication = No" to smb.conf.
As far as Group Policies are concerned, only basic & essential group policies were created and enforced on all users / workstations. Additionally, in order to enforce NTLM v2, specifically on Windows XP workstations, a Group Policy was created to force NTLM v2 authentication.
A specific web portal was customized for the bank to allow user self service that is, update their profile, change their password including "Forgot Password Option", user search etc
Partial List of Devices / Applications integrated with AD
Internet Proxy with single sign on - Forcepoint Websense
NextCloud - File sharing platform for the Bank
OSTicket - Internal HelpDesk Application
Bank's Internal Audit Applications
Banks Online Grievance Portal - Bank's Customer Help Desk
Very shortly, even the Core Banking Application will also be integrated with Samba-AD thus completing all integration process.
Privileged Identity And Access Management Practice
With almost all servers / network devices including many Linux servers, KVM / oVirt, Cisco ISE, Internet Proxy etc., already integrated to be members of AD, no user is allowed to log in to any server / network / security device using Privileged / anonymous accounts accounts like "root", "Administrator", "admin" etc. All administrators are allowed to to log into the respective servers / devices using their AD user name and access is provided based on their defined role and access rules in AD. Logs of all such logins are captured both in AD and device / application level and stored in a common place for analysis, thus sowing the seeds for Privileged Identity and Access Management Practice.
Although there were many challenges during the setup and roll out, Samba-AD project added a significant value to the whole setup. At the time of writing this article, nearly 5000 workstations were added to AD Domain as members across country. I must thank one and all in the community for providing such a wonderful platform and an excellent support.