Totally Automated Security (TAS)

1. Totally Automated Security (TAS) Mark Nichols Louisiana Department of Education (LDOE) March 6, 2007

2. TAS • TAS is a web-based system • TAS ‘integrates’ RACF and Active Directory security • TAS allows LDOE enterprise, local public school districts, and private school Security Coordinators (SC) to inquire and update existing users’ security permissions. • TAS allows SC’s to create new users • TAS ‘integrates’ our Data Transfer Management System (DTM) with its own application security

3. TAS • TAS is a web-based system • TAS is written entirely in Microsoft ASP running on a Windows Server 2000 IBM Blade • TAS is not browser specific

4. TAS • TAS ‘integrates’ RACF and Active Directory security • LDOE is migrating from the IBM mainframe to Windows servers • ‘Parallelism’ was chosen for the RACF to AD migration • Users would keep same Userids and passwords • Existing userids were ‘copied’ from RACF to AD • P-Synch, a password synchronization product, was purchased and deployed • User security roles (RACF and AD group membership) would remain equivalent

5. TAS • First, small application systems were migrated to Windows and one new systems was written in Windows. Immediate confusion. • LDOE’s Security architecture • Local SC’s and security forms • Non-public Schools entered the mix • New system written in Windows • Doubled number of school users • Non-Public School users do not need a RACF ID • New applications will require many more users • “Where/What is the security problem?” • “What security (Windows and RACF) does a user have?”

6. TAS • TAS to the rescue? (or Necessity is the Mother of Invention) • Called lots of vendors: “Do you have a security product that will interface with RACF and AD”. Lots of silence. • Can I write something that would inquire on AD and be interactive and web-based?

7. TAS • The evolution of TAS • Write it in PHP or ASP? • More familiar with PHP • PHP is stronger in Lightweight Directory Access Protocol (LDAP) • ASP has native AD interfaces • ASP will run with no IIS changes • PHP must be installed and maintained • Planned to place TAS inquiry (if it could be written) on the production IIS Web server. • PHP would have to be installed and maintained • Any IIS problem could be blamed on PHP • Hope that Applications Development will one day assume maintenance of TAS (no chance of this if written in PHP)

8. TAS • The evolution of TAS (continued) • Discovered necessary function scripts on the web (Microsoft’s “Scripting Guys” were especially helpful) • Wrote the code for Windows inquiry for the Enterprise Security Coordinators (ESC) – it worked – they liked it and had a question “Could you integrate RACF also”? • Get Microsoft ASP to talk to and pull users and groups out of RACF? No way! Or maybe there was. • RACF does have LDAP capability (the ‘proc’ LDAPSRV). Does ASP have enough ‘open system’ LDAP functionality to read IBM’s version of ‘open system’ LDAP? • Do I have enough functionality to understand and decode command line LDAP?

9. TAS • The evolution of TAS (continued) • The answer to both above questions was ‘yes’. TAS now displayed a given userid’s AD and RACF roles (group memberships) on a web page • The ESC’s then stated, “We are always asked by the Local Security Coordinators (LSC) • “What security does this userid have”? • “Who in my district has userid’s”? • Can the LSC’s use TAS”? • This required writing a ‘real’ front end and wrapping the reports with an user interface. TAS is going ‘Production’.

10. TAS • The evolution of TAS (continued) • To allow LSC’s to inquire on their users some RACF and AD configuration changes were necessary: • RACF required organizational changes with new groups and groupings (userids moved into the new groups) • AD required new security groups

11. TAS • The Eureka Moment • Reorganizing RACF and AD to allow LSC’s to inquire only on their own users are almost the exact steps needed to allow the LSC’s to update their own users in RACF and AD • Do we want to allow the LSC’s to do their own security maintenance? • Writing ASP scripts to update AD (adding user IDs, modifying group membership) is now with within our skill level.

12. TAS • The Eureka Moment (continued) • The 80 – 20 rule • TAS with update capability would be written to process only ordinary security request • This encompasses 80% - 90% of the total security request received • The 10% - 20% of extraordinary security request would continue to be handled manually with security forms

13. TAS • The Eureka Moment (continued) • Could RACF be modified by ASP? • Could not find any LDAP modification commands using ASP anywhere • Is another mechanism available? • We ‘Webified’ our IBM mainframe around 1998 • Secure HTTP Server (HTTPS://) has been in production on the Internet since 1999 • FTP has been available ‘inside the firewall” for DOE internal use only since 1999

14. TAS • The Eureka Moment (continued) • FTP • There was something about FTP server and the ‘card reader’ • Looked up the FTP server info • The FTP command ‘SITE’ • Sending the command “quote site FILE=JES” will cause the Mainframe FTP server to ‘write’ the file being ‘put’ or sent to the server to the JES card reader

15. TAS • The Eureka Moment (conclusion) • Will ASP FTP a file containing JCL to JES to modify RACF? • YES! TAS now updates AD and RACF • The ESC’s and Non-Public School SC came for a demo. Can TAS also interface with DTM our ‘home grown’ data transfer application system which stores its security data in DB/2? • YES, TAS now automates all ordinary Security request

16. TAS • Conclusion • TAS was written out of absolute necessity • Non-Public School reporting doubled the number of userid’s • 5000 more userids are soon to be added (SER/IEP) • TAS evolved beyond any anyone’s expectations • What began as a ‘quick and dirty’ AD inquiry program for two users quickly evolved into a enterprise-wide linchpin production system for LDOE • Demonstration & Questions