1 / 12

TWSd Configuring Tivoli Workload Scheduler Security 1of3

TWS Education + Training April 29-May 3, 2012 Hyatt Regency Austin Austin, Texas. TWSd Configuring Tivoli Workload Scheduler Security 1of3. 3202 Wednesday, May 2, 2012. Overview. Architecture Authentication Authorization Accounting. Architecture. TWS security components

colum
Download Presentation

TWSd Configuring Tivoli Workload Scheduler Security 1of3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TWS Education + TrainingApril 29-May 3, 2012 Hyatt Regency Austin Austin, Texas TWSd Configuring Tivoli Workload Scheduler Security1of3 3202 Wednesday, May 2, 2012

  2. Overview • Architecture • Authentication • Authorization • Accounting

  3. Architecture • TWS security components • Active Directory – LDAP registry • WAS/eWAS • DB • WebUI - TDWC • CLI

  4. Architecture eWebSphere Application Server Active Directory LDAP registry Master Domain Manager DB2 or Oracle RDBMS Distributed Installation Tier 1 WebUI/ TDWC BKDM Engine MDM Engine WebUI/ TDWC Fault Tolerant Agent CLI FTA3 External WebSphere Application Server FTA1 FTA2 UNIXLOCL XA UNIXSSH XA SAP XA

  5. Authentication • Confirming your identity - Are you who you say you are? • Authentication Registries • LocalOS • LDAP • CUSTOM – PAM (LDAP and LocalOS) • Active Directory - LDAP • TWS TDWC and CLI users Authenticate against the AD domain • How? • On startup, the websphere application server connects to the LDAP (Windows AD) using a LDAP bind user • The User is presented with the WebUI (TDWC) login screen and needs to enter his AD user and Password • eWAS presents these credentials to the LDAP for authentication • The user group member ship is identified and if the group is defined in the eWAS registry, the user is allowed access into the TDWC on successful authentication

  6. Authorization • What are you allowed to see and do? • Authorization model • The TWS user’s group membership in AD LDAP determines what authorization they are allowed • Authorization can be assigned at Group or User level • TWS access groups can be mapped to roles in the WebUI and in the Security file • Group level authorization – means less user administration • Read Only access may be added for any domain user that is authenticated, but not defined in a TWS access group • Where is the authorization defined? – on two levels • In the WebUI (TDWC) registery on a user and/or group level (What can you see and work with in the WebUI) • In the TWS Security file on the Master Domain Manager server (What are you allowed to do) • How? • During authentication, the users group member ship is identified and if the group is defined in the eWAS registry, the user is allowed access according to what is defined • The TWS security file will manage what a user/group is allowed to do in the Engine and Database • The security file on the engine determines Authorization.

  7. Authorization (Cont.) • Advantages • All authentication against a single repository • Each environment has its own access configured (Dev, QA and PROD) using the same authentication group • Application Groups can have update access in Dev and QA , but read only access in Prod • Production Support has update access in Dev, QA and PROD • Operations support have Operator access PROD (and QA where required) • CLI – User authentication against AD using the User/password stored in the .TWS/uid_useropts file (UNIX/Linux) • Granular user control can be implemented if required • No individual user management is required from the TWS admin • TWS access Group membership is determined by the Application Owner – Business determines access • Disadvantages • Bind user is a single point of failure – locking the bind user, stops all access to TDWC

  8. Authorization – WebUI registry

  9. Authorization – TWS Security File

  10. Authorization – Access Matrix example

  11. Accounting • How do we track updates on TWS Plan and Database? • Switch on AUDIT using “optman” (0=off 1=on) • enDbAudit / da = 1 • Optman chg da = 1 • enPlanAudit / pa = 1 • Optman chf pa = 1 • The files can be found in /$TWSHOME/audit/plan or /$TWSHOME/audit/database • Now you can see who did what and when

  12. Simple Problem Determination • Unable to log into the WEBUI (TWS url) LocalOS • User id locked on unix/windows LDAP/AD • Does the user id belong to you authentication AD domain? • The user id may require a password change? • The user id may be locked? • The user is not defined in a TWS group (only if all_authenticated user login is not allowed) • TWS bind is locked – all user logins will fail • User does not have view/modify access on WEBUI • Users group roles do not allow view/modify access • User gets no access allowed when working on the WEBUI and clicking on a modify task • This user group may not have the access defined in TWS Security file for update access, or is not allowed modify access in the group stanza

More Related