success stories from it consolidations n.
Skip this Video
Loading SlideShow in 5 Seconds..
Success Stories from IT Consolidations PowerPoint Presentation
Download Presentation
Success Stories from IT Consolidations

Success Stories from IT Consolidations

0 Views Download Presentation
Download Presentation

Success Stories from IT Consolidations

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Success Stories from IT Consolidations Corinne Irwin Karen Petraska John Sprague

  2. Consolidation Success Stories • I3P continues NASA trend to provide consolidated enterprise IT services • Consolidations often perceived negatively: loss of local control, end-user focus • ICAM, NCAD, and NOMAD are three examples of Consolidation success stories • These consolidations provided enhanced: • Collaboration • Mobility • Scalability • Security • Simplicity of Architecture • Data and System integration • And yes, cost management Presentation Title—2—March 5, 2010

  3. NASA’s Identity, Credential and Access Management Consolidation

  4. What is ICAM? Identity, Credential, and Access Management provide Agency tools to answer these key questions: • Who are you? • How do you prove it? • What can you use? • Get more details at: •

  5. Before ICAM • Ten or more implementations each for: • Identity Management • Badge Issuance • RSA Token accounts • Directory Services • More…. • Isolated stovepipes or complex meshes • Need for paper processes to allow inter-Center collaboration • Slow, laborious Presentation Title—5—March 5, 2010

  6. The Consolidation • Identity: A single, authoritative identity store for everyone that does business with NASA • Decommissioned Center x.500s and local identity systems • Credential: A few Agency credentials to access most facilities and systems • We have already retired hundreds of application-unique passwords • Physical Access: An Agency-wide system for all physical access to buildings and rooms • Logical Access: • NASA Account Management System (NAMS) allows access to over 1,000 applications • A single Active Directory forest/domain • The Access Launchpad for access to web applications • Consolidated RSA infrastructure for two-factor access where smartcards cannot be used Presentation Title—6—March 5, 2010

  7. ICAM Logical AccessService Description

  8. Integration of NCAD and Launchpad User’s desktop login allows pass-through access to any Launchpad application.

  9. Collaboration • Smartcard login to the desktop, then get to over 500 applications without re-logging in • Access to Agency applications without a separate process to validate the user’s identity Mobility • Any NASA worker can visit any NASA Center, and get: • Pre-authorized access to any building/room • Wireless access to the NASA network Presentation Title—9—March 5, 2010

  10. Simplicity of Architecture • Literally hundreds of systems replaced with a handful • Over 1,000 paper forms replaced with a single system for account access • Hundreds of thousands of UserIDs/passwords retired Cost Management SATERN migration: 80% drop in help desk calls for logon issues, account locks, and password resets Presentation Title—10—March 5, 2010

  11. Security • We can ensure on a person-by-person basis that those who need IT security training have taken it • We know what each person has access to • When someone leaves NASA, we can immediately: • Disable AD and Launchpad accounts • Revoke PKI Certificates and Tokens • Close Accounts managed in NAMS Presentation Title—11—March 5, 2010

  12. Data & System Integration • SATERN Integration • Ensures IT security training is complete • Can set other training courses as pre-requisites for any access granted through NAMS • Provide “Basic Level of Entitlement” access to IT systems based on Identity attributes • Various Directories all “match:” • IdMAX • NCAD • NOMAD GAL • NASA Enterprise Directory Presentation Title—12—March 5, 2010

  13. Considerations • NASA’s ICAM allows Trust throughout the Federal government and beyond • First, NASA must trust NASA • Configuration settings needed on desktops, networks, to enable NASA Trust • Any change that is managed locally is difficult to manage well • Centrally managed infrastructure services provide a standard baseline against which we can assess the impact of changes, be they new federal mandates or implementation of new functional requirements. • At the same time, a single change impacts the entire Enterprise • Is everyone ready? • Has it been thoroughly tested? • Any unintended consequences? Presentation Title—13—March 5, 2010

  14. NASA’s Active Directory Consolidation

  15. NASA Consolidation of Active Directory • Active Directory is a Microsoft tool that • Serves as a directory of people in the environment • Provides an authentication mechanism to AD-aware applications • Provides a coordinated management environment of groups, objects, and policies for an organization • In most organizations, when you log in to your Windows or Mac computer, you are authenticating to Active Directory Presentation Title—15—March 5, 2010

  16. Historical Perspective • NASA historically did not manage Active Directory as an integrated environment for the Agency • Many small organizations had their own AD instances. There were likely more than a hundred domains Agency-wide, including child domains and individual instances of AD, and an unknown number of workgroups • In many cases, user accounts from different organizations were issued for specific internal purposes; collaboration using a common credential was not possible • Organizations established external “trust relationships” that were managed with no common set of criteria and could compromise connected NASA resources Presentation Title—16—March 5, 2010

  17. The Consolidation • Began in 2006, completed in Summer 2010 • Migrated 57,000 desktops; 66,000 users; 3,700 servers • Reduced to a single forest, single domain • Eliminated all 35 two way trusts • Allowing eleven one way trusts (they trust us, we do NOT trust them) to continue to exist temporarily • Replaced hundreds of domain controllers with 65 for the entire Agency • Reduced an unknown number of AD domain administrators (>100) to eight Presentation Title—17—March 5, 2010

  18. Overall Improvements • Designed to enable mobility • In most cases, residents from one NASA center can go to another NASA center, put their laptop on the network and it works! • Working toward getting access to home resources like file shares and printers • Enables users from various centers to collaborate across centers • Enables push of consistent policies across the Agency • Enables seamless access to authenticated wireless and applications across the Agency Presentation Title—18—March 5, 2010

  19. Security Implications • A single, simplified, centrally managed infrastructure that we have full control over and full understanding of what it is • Deployed a continuous security monitoring tool across all of AD. Events of all kinds reported and investigated instantly. • Deployed a third party management system that tightly and granularly controls configuration changes and who can make them • By eliminating and prohibiting trusts with entities containing non-ICAM vetted user accounts, we have a clear view of who we plan to allow into our systems • We can enforce consistent security and management policies on all objects Presentation Title—19—March 5, 2010

  20. Considerations • A change of this magnitude with such a large number of migrations is a huge coordination and project management challenge • In addition to requirements, design and operational readiness reviews, we did a migration readiness checklist , migration readiness review and migration completion review at each center • Simple, understandable outreach materials for end users are essential • Do not underestimate the level of effort needed to get buy-in and cooperation from all those organizations who are losing control of their domains. Presentation Title—20—March 5, 2010

  21. NASA’s Email Consolidation

  22. NOMAD NASA Operational Messaging And Directory Service A consolidated Microsoft Exchange-based groupware infrastructure for all NASA civil servants and contractors Presentation Title—22—March 5, 2010

  23. NOMAD Origins • In 2004, Administrator O’Keefe directed the NASA CIO to transform how NASA provided IT services to the Agency workforce • At the heart of the memo was the direction to provide an integrated messaging and calendaring solution allowing NASA to communicate as a single entity. • First center (HQ) fully migrated in March 2005 • By 2008 and 4 CIOs later, all 10 major NASA centers are migrated onto NOMAD Presentation Title—23—March 5, 2010

  24. Goals • Provide a uniform messaging and calendaring environment • Integrate both civil servants and contractors • Offer access from anywhere • Increase security • Use open standards for interoperability • Support NASA’s heterogeneous environment • Minimize downtime and single points of failure • Leverage existing resources • Reduce costs • Allow the Agency to focus on bigger issues Presentation Title—24—March 5, 2010

  25. NOMAD is an integrated system of systems Over 175 Servers Windows Linux Mac OSX 9 Major Subsystems Exchange Servers NASA Post Forwarders/Relays Archiving System Live Communication Server IM System Center Monitoring ProofPoint Security System Blackberry Servers Large File Transfer System Virtual Test Environment 2 Fault-tolerant Locations JSC MSFC Presentation Title—25—March 5, 2010

  26. NOMAD Consolidation Benefits • Mobility • Scalability • Security • Uniformity • Cost Management • Visibility • Culture Change Presentation Title—26—March 5, 2010

  27. Mobility • Issue • NASA is a globally distributed and very mobile population • NASA’s centers have a variety of firewall policies and configurations • Solution • To guarantee access from any center or facility, NOMAD was designed to be an “external” service • Similar to many of today’s cloud offerings • Most O/Ss and devices are enabled through a suite of secure access protocols Presentation Title—27—March 5, 2010

  28. Scalability • NOMAD’s first user quantity was about 4,000 • Today, NOMAD supports around 60,000 users • The fundamental design of the system has not changed between those two capacities, just the number of servers • NOMAD was architected to continue to scale to meet NASA’s needs • The dual-site fault-tolerant architecture allows us to load servers and storage systems with only a 50% load Presentation Title—28—March 5, 2010

  29. Security • By drastically decreasing the number of email servers across the Agency, consolidating to NOMAD reduced the attack surface • Entire Exchange backend infrastructure can only be accessed via client access servers • Multiple layers of security are applied against viruses, malware and vulnerabilities • A variety of anti-virus engines and databases are actively scanning at all times • Multiple firewalls and security zones isolate access as appropriate • Agency security policies can be enforced Presentation Title—29—March 5, 2010

  30. Uniformity • Users all have an @NASA.GOV address • A NASA identity is a NASA identity regardless of the center they currently reside at • Every NOMAD provisioned desktop, laptop and smartphone can access NOMAD services regardless of where they are • An Internet Café network looks exactly the same as a NASA center network • Since NASA must comply with federal standards and regulations, a consolidated messaging system furnishes a consistent application of governance Presentation Title—30—March 5, 2010

  31. Cost Management • Did NOMAD reduce the cost of messaging across the Agency? Who knows???? • What we do know is… • Hundreds of servers retired • Numerous folks are no longer managing email servers and can focus on more important activities • Software licenses united • Hardware consistently refreshed • NASA now has an understanding of the cost to provide email “You cannot manage what you cannot measure” Presentation Title—31—March 5, 2010

  32. Visibility NASA understands its messaging traffic better than ever before Presentation Title—32—March 5, 2010

  33. Culture Change Presentation Title—33—March 5, 2010