• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Addmi 14-discovery credentials
 

Addmi 14-discovery credentials

on

  • 544 views

 

Statistics

Views

Total Views
544
Views on SlideShare
539
Embed Views
5

Actions

Likes
0
Downloads
33
Comments
0

1 Embed 5

http://www.techgig.com 5

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • The Windows Slave will inherit the authority and rights of the credential used to run it as a service.
  • No credential details from the Vault are ever stored in the Datastore only the credential key. Each appliance has it’s own vault, they are not shared.
  • The Vault encryption is genuinely secure there are no back doors for Tideway Support. If a specific vault passphrase is set and forgotten it cannot be recovered.
  • Changing the passphrase briefly cycles the vault closed in order to change the encryption. Discovery should not be running while this happens as it expects the vault to be open.
  • We will cover SSH Key Exchange in a moment
  • By default all access types are enabled. First scan performance might be increased if only the relevant access types are enabled as otherwise discovery will try and establish more sessions than it needs to. For UNIX credentials at least the windows type should be disabled. In modern environments using SSH rlogin and telnet can also be disabled. If the access types are left as default then all your UNIX credentials will also be used via a Credential Slave if one is attached. Additionally if telnet is left enabled and a wide IP Range is set then the credential will be tried against many telnet enabled IP devices that are probably not Hosts.
  • Some sites run SSH on custom ports for a variety of reasons. This option allows you to define a custom port. Note that Discovery will amend the list of ports scanned on the initial scan to include this port so it can detect it; you may need to talk to security stakeholders to also amend firewall rules or approve this change.
  • The warning is important. Generating a new key pair will overwrite the existing one and invalidate any deployed public key. Should a user do this by ignoring the warning on the UI and then clicking through the warning dialogue then there is an undocumented safety net in that any existing key will be moved to a “*.bak” file on the filesystem. They should contact support for advice on how to restore the keys. Only the most recent old key is backed up as the *.bak files are overwritten on each generation.
  • If you have both password and key exchange accounts for the same username it is best practise to set up two credentials, one with a password and one without and order them so the non-password credential is first. This will greatly aid discovery in monitoring the credential.
  • Credential slaves can now be shared between appliances, but each appliance can still only use a single credential slave The Workgroup Slave is rarely deployed but it functions in an identical way to the Active Directory Slave for environments that still have the older Workgroup style of deployment.
  • Note that only a single credential slave can be added after which the “Add Credential Slave” button will be greyed out If a Slave is installed by an installer downloaded from a particular appliance it will automatically attempt to connect itself to that appliance during install so this step may not be needed.
  • Note that only a single credential slave can be added after which the “Add Credential Slave” button will be greyed out
  • By default all access types are enabled. First scan performance might be increased if only the relevant access types are enabled as otherwise discovery will try and establish more sessions than it needs to. For Windows credentials all the UNIX types should be disabled. If the access types are left as default then all your Windows credentials will also be used against SSH/Telnet hosts. Additionally if telnet is left enabled and a wide IP Range is set then the credential will be tried against many telnet enabled IP devices that are probably not Hosts.
  • Restricting a slave will help first scan performance if there are a large number of slaves configured as it will allow Discovery to only try those slaves that can access the endpoint.
  • The list must be have an IP per line. The format of the IP is restricted to either a full single IP or a backslash range definition. No wildcards can be entered. The List is canonical – if a new list is uploaded it overwrites the existing one. If you want to edit or extend and existing list then download it from the slave first.
  • Ideally ask for a specific Tideway Read Only community string. If not many SNMP devices will report basic information with a “public” community string but not this will not gather information such as processes
  • Netware discovery will only respond using a Version 1 protocol. Currently our SNMP library does not support Version 3 protocol.
  • If the TKU_DBDETAILS pattern packages are not installed
  • You will need to click on the credentials link for the product the credential is for.
  • Consult your DBA on which driver is best
  • For example say you are scanning an endpoint of 10.0.0.10 and find the ssh port is open. Discovery will look in the Vault for any credentials who’s IP range matches 10.0.0.10 and have the SSH access type set. Let’s say there are 3 credentials that match both of these; Discovery will start with the top one and try to establish a session. If it can’t it will try with the second one and so on. It will stop when it gets a successful session or runs out of credentials that match.
  • The following best practices will help you maximise throughput of first scan and get the highest quality data. Remember after the first scan discovery will cache the successful credential so it can quickly create a session on future scans without trying all the credentials. 1) To make sure you have high quality data, put the higher privilege accounts first in the list. Discovery only cares about establishing a session so if a public credential works (but doesn’t have authority to run some of the commands) it will not try the root credential below it! For Windows Slaves if you have an AD slave service that runs with more authority then put it first. 2) If you have a global credential put this *after* any machine specific credentials. This means the specific credentials will be tried first. This applies to Windows Slave ordering as much as UNIX login credentials – put your Credential slave ahead of your AD slave if you have specific windows credentials so they are tried first.
  • 3) If you have both an ssh key and ssh password credentials put the key ones first. This will not really impact efficiency but if you order them this way it will be very clear which hosts are using key exchange and which are using passwords. If you put the password credential *first* then this credentials will be always be tried first and you will be unable to tell where you have key deployment issues. 4) Try to use specific ranges where possible. If you have several general credentials and they are all dot-star or catch-all IP ranges then they will all be tried on all hosts. If you have several AD slaves and you have not restricted them then they will *all* be tried as well.
  • 5) If you have several general credentials put the ones you expect to work most often before the others. This way Discovery spends less time on credentials that may not work for all hosts. 6) Only have relevant access types on your credentials. If you leave the access types as default the credential will be tried for all UNIX, Windows and Telnet enabled devices. This is very inefficient and will slow down discovery, considerable on the first scan.
  • If you want to test if a Host is discoverable then do a single IP scan of that Host or use the “Rescan” option on the Action menu for the Host node or one of it’s DiscoveryAccess nodes.
  • Credential testing is availble from the “Action” menu of both a Host and DiscoveryAccess node view to aid in debugging credential issues. Note that you can also trigger a full discovery rescan too for the same reasons.
  • The difference here is that we are not asking Discovery to try all the credentials at it’s disposal to access the endpoint, we are asking that specific slave if it can establish a session with the endpoint. This can be useful in tracking down slaves that have access issues, maybe because of a previously unknown firewall.
  • It’s important these are done from the CLI as the user “tideway” as this replicates what Discovery will do. SSH – accepting the RSA identity is what discovery will do. If the username was anticipated to be an SSH key exchange and a password is prompted for then the key on the rmeote host is not correct. In all cases ensure you get an interactive shell up.
  • It’s important these are done from the CLI as the user “tideway” as this replicates what Discovery will do.
  • It’s important these are done from the Host that is running the slave logged in as the user that is running the slave service.
  • It’s important these are done from the Host that is running the slave logged in as the user that is running the slave service.
  • It’s important these are done from the Host that is running the slave logged in as the user that is running the slave service.

Addmi 14-discovery credentials Addmi 14-discovery credentials Presentation Transcript

  • Discovery Credentials Giving Atrium Discovery Authority to Discover
  • Outline
    • Vault
    • Unix
      • Login
      • SSH key
    • Windows
      • Slave Choice
    • SNMP
    • Software Credentials
    • Credential Ordering
    • Testing and Debugging Credentials
  • How Do We Get In?
    • To access your environment Atrium Discovery needs credentials
    • These are provided in two ways
      • Entered locally on the appliance where they are stored in the Vault
      • A Windows Discovery Slave is configured to run as a service on an external host using a specific credential
  • The Vault
  • What Is the Vault?
    • The Vault is a passphrase encrypted store for credentials
      • Blowfish encryption
      • 64 Character/512 bit default passphrase
    • Vault is opened/closed in sync with Discovery start/stop
    • Only Discovery sub-system can access the Vault
    credential vault Your IT estate discovery process
  • Advanced Vault Management
    • If required a specific Vault Passphrase can be set
      • Only advised if security conditions require it as the passphrase will need to be entered every time Discovery is started
    • Administration > Discovery > Vault Management
  • Changing Vault Passphrase
    • Stop Discovery
    • Enter the new passphrase twice
    • Click “Set Passphrase”
    • Remember it’s a pass phrase not a pass word
      • Make it long otherwise the encryption will be weakened
  • Starting Discovery with Passphrase
    • With a passphrase set on the Vault you will need to enter it every time discovery is started
    • You will also need to enter it to view credentials
  • UNIX Credentials
  • Basic UNIX Credentials (1)
    • UNIX Credentials are stored in the Login Credentials section
    • Discovery > Credentials > Login Credentials
  • Basic UNIX Credentials (2)
    • Click the “Add” button to get the credential editor
  • Basic UNIX Credentials (3)
      • Enter a range of IPs that this credential is valid for
        • 10.0.0.1 – Single IP
        • 10.10.10.* or 10.10.1-5.* or 10.10.10.0/24 - range specification
        • .* or 10.10.10.(23|25) - regex
  • Basic UNIX Credentials (4)
      • Enter the username of the credential
  • Basic UNIX Credentials (5)
      • Enter the password of the credential
  • Basic UNIX Credentials (6)
      • Enter a description of the credential to aid credential management
  • Basic UNIX Credentials (7)
      • Choose which access types this credential is valid for
      • Click “Apply” button to commit the credential to the Vault
  • UNIX Credentials Advance Options (1)
    • If you wish to su to root or a higher privileged account after login
      • Set the “SU” option
      • Provide the username
      • Enter the password ( if the account has a password set)
  • UNIX Credentials Advance Options (2)
    • If you know that SSH runs on a different port for these IPs
      • set the “Enable custom SSH port” option
      • enter a custom port here
  • SSH Key Exchange UNIX Credential (1)
    • SSH can use a key exchange as a more secure alternative to passwords
    • To generate a fresh key click “Generate RSA keys”
      • Do not generate keys if one is already in existence and the public key has been deployed!
  • SSH Key Exchange UNIX Credential (2)
    • To tell discovery to use key exchange set up a username with no password
  • Windows Credentials
  • Windows Credentials Basics
    • For Windows credentials you have two choices
      • Store credentials locally in the Appliance Vault and use a Credential Slave to proxy the discovery
      • Deploy a Active Directory or Workgroup Slave which will run as a service under a Domain/Workgroup credential and proxy the discovery
    usernames, passwords Connects to estate with supplied username/password Delegates discovery to Windows slave Connects to the estate using the slave’s Windows Service account Delegates discovery to Windows slave Your IT estate discovery process credential vault Credential Slave Your IT estate discovery process Active Directory Slave
  • Which Slave to Use
    • Large Scale Deployments
      • Active Directory Slave
      • Least painful way of managing and deploying credentials
      • Works best with increasingly tightening Microsoft security approaches in Server 2008 and Vista: User Account Control UAC
      • Can have multiple AD Slaves to cope with many Domains
    • Test Lab, trials, small networks
      • Credential Slave
      • Have to create and deploy individual credentials
      • May need additional work on some servers to allow remote administration level rights
      • Can only connect a single Credential Slave per Appliance
  • Credential Slave Overview
    • Credentials Required
      • Tideway Slave runs as a service on customer hardware
      • Administrator credentials are required to be setup in the Appliance (Vault)
    • Many-to-One
      • An appliance may configured for at most one Credential Slave
      • A Credential Slave may be shared between appliances
    • Default Port: 4323
  • Active Directory Slave Overview
    • Credentials Required
      • Runs as a service as Domain Administrator
      • No Administrator credentials required on the Appliance
    • Many-to-Many
      • An appliance may configured for more than one AD/Workgroup slave
      • An AD/Workgroup slave may be shared between appliances
    • Default ports: 4321 (AD), 4322 (Workgroup)
  • Connecting a Windows Slave (1)
    • Discovery > Credentials > Slave Management
    • Click on the appropriate “Add x Slave” button
  • Connecting a Windows Slave (2)
    • For a Credential Slave
      • Provide a name and the Slave Host IP address
      • Take the default port and click “Apply”
  • Connecting a Windows Slave (3)
    • For an Active Directory Slave
      • Provide a name and the Slave Host IP address
      • Provide the domain
      • Take the default port and click “Apply”
  • Basic Windows Credentials for Credential Slave
      • Add under Login Credentials just like basic UNIX credentials
      • Ensure the only access type is only windows
      • Make sure you have a Credential Slave!
  • Restricted Slave (1)
    • If you know a Windows Slave can only access a particular part of the network you can restrict it
    • This works like the IP Range on Login Credentials
  • Restricted Slave (2)
    • Check the “Restricted” option to enable the feature
    • Upload a file of restricted IPs
      • Can only have the form
      • 10.0.0.1 – single IP
      • 10.0.0.0/24 – range
    • Download the existing “Allowed IPs” list first if extending
  • Slave Self Scanning Limitation
    • Windows authentication works differently if commands are run locally
    • This means that a Slave, in general, cannot discover it’s own Host as it uses remote authentication
    • A common gotcha in testing and small trials
  • SNMP Credentials
  • SNMP Credentials (1)
    • SNMP Credentials are stored in the SNMP Credentials section
    • Discovery > Credentials > SNMP Credentials
      • Click the “Add” button to get the credential editor
  • SNMP Credentials (2)
      • Enter a range of IPs that this credential is valid for
        • 10.0.0.1 – Single IP
        • 10.10.10.* or 10.10.1-5.* or 10.10.10.0/24 - range specification
        • .* or 10.10.10.(23|25) - regex
  • SNMP Credentials (3)
      • Enter a community string
  • SNMP Credentials (4)
      • Enter a description of the credential to aid credential management
  • SNMP Credentials (5)
      • Set the correct protocol version
      • Click “Apply” button to commit the credential to the Vault
  • Software Credential Groups Database Credentials
  • What Are Software Credential Groups
    • If you have installed patterns that query Databases you will have Software Credential Groups
      • TKU_DBDETAILS
    • Credentials are grouped by Software Product
  • Software Credentials Groups (1)
    • Used by patterns that interrogate relational databases via JDBC
  • Adding Software Credentials (1)
    • Click on “Credentials”
    • Click on “Create New Credential”
  • Adding Software Credentials (2)
      • name – use the username
      • description – to help credential management
      • username – enter the database user name
      • password – enter the database user’s password
      • database driver – you will need to select the correct JDBC driver
  • Adding Software Credentials (3)
    • Database credentials need the appropriate DB driver selected
      • Consult your DBA on the correct one to use
    • You may need to upload the actual JAR file
      • Administration > JDBC Drivers
      • Shows status of loaded drivers and links to vendor sites
      • Consult an appropriate DBA if needed
  • Adding Software Credentials (4)
      • Enter a range of IPs that this credential is valid for
        • 10.0.0.1 – Single IP
        • 10.10.10.* or 10.10.1-5.* or 10.10.10.0/24 - range specification
        • .* or 10.10.10.(23|25) – regex
      • Ignore other fields, the TKU patterns will provide this data on the fly as needed
    There are a number of advance feature options in this area which are not needed for basic discovery
  • Credential Ordering
  • Credential Order and Re-ordering
    • All credentials are ordered and will be tried in turn, if more than one matches the IP and access
      • Ordering is top to bottom
      • They can be re-ordered by dragging the credential box
  • Credential Order Best Practise (1)
    • Have root accounts before restricted ones
    • Have specific credentials before general ones
    • If you have both an ssh key credential and ssh password credentials put the key ones first
    • Try to use specific ranges and not .* if you have several general credentials
    • If you have several general credentials put those you expect to work most often before the others
    • Only have relevant access types on your credentials
    • Discovery will be most slowed down by Hosts it can detect and spend time trying all the credentials it can
  • Credential Order Best Practise (2)
    • Have root accounts before restricted ones
    • Have specific credentials before general ones
    • If you have both an ssh key credential and ssh password credentials put the key ones first
    • Try to use specific ranges and not .* if you have several general credentials
    • If you have several general credentials put those you expect to work most often before the others
    • Only have relevant access types on your credentials
    • Discovery will be most slowed down by Hosts it can detect and spend time trying all the credentials it can
  • Credential Order Best Practise (3)
    • Have root accounts before restricted ones
    • Have specific credentials before general ones
    • If you have both an ssh key credential and ssh password credentials put the key ones first
    • Try to use specific ranges and not .* if you have several general credentials
    • If you have several general credentials put those you expect to work most often before the others
    • Only have relevant access types on your credentials
    • Discovery will be most slowed down by Hosts it can detect and spend time trying all the credentials it can
  • Best Practices Example (1)
    • The specific credentials are at the top of the list
    • The key credential is before the password
    • These are specific admin accounts so have high access rights so are at top
    10.0.0.1 – ssh (key) admin 10.0.0.1 – ssh (password) admin 10.0.0.* – ssh (password) root 20.0.0.* – ssh (password) root .* – ssh (key) discovery-user .* – ssh (password) backupagent
  • Best Practices Example (2)
    • The general credentials have well defined ranges
    • These are root accounts so have high access rights so are above the more general accounts but below the specific admin accounts
    10.0.0.1 – ssh (key) admin 10.0.0.1 – ssh (password) admin 10.0.0.* – ssh (password) root 20.0.0.* – ssh (password) root .* – ssh (key) discovery-user .* – ssh (password) backupagent
  • Best Practices Example (3)
    • The general “discovery-user” credential that is being rolled out should work most places so it is above the “backupagent” credential that might work on only a few machines
    • We expect the “discovery-user” credential to have more rights than “backupagent” but not as much as the specific root/admin credentials
    10.0.0.1 – ssh (key) admin 10.0.0.1 – ssh (password) admin 10.0.0.* – ssh (password) root 20.0.0.* – ssh (password) root .* – ssh (key) discovery-user .* – ssh (password) backupagent
  • Testing Credentials
  • Testing from the Credentials UI
    • Credentials can be tested from within the system
    • The check will test if a session can be established
      • BUT it cannot test commands from discovery or patterns so it is not a guarantee that discovery will be successful just that a connection can be made
  • Other Locations for Credential Tests
    • From a Host
    • From a Discovery Access
  • Testing IP Access
    • Select “Test IP Access” and enter a single IP
    • Test will run in background
  • Viewing IP Test Results
    • Click on the result to see details
    Summary Detail
  • Testing Slave Connectivity and Access
    • Use the Ping option in the Actions menu to check Appliance to Slave connectivity
      • The result of the ping will be shown in the information banner
  • Testing a Specific Slave IP Access
    • Select “Test” from the “Actions” menu and enter a single IP
    • Test will run in background
  • Testing Low Level Access
    • Sometimes it is useful to confirm that credentials work at a low level outside of the Discovery service
    • There are separate procedures for each type of credential
      • UNIX
      • SNMP
      • Windows
  • Testing UNIX Credential
    • Test from the Appliance CLI as the user ‘tideway’
    • SSH
      • ssh <username>@<ip>
      • accept identity if prompted
      • enter password if prompted
    • Telnet
      • telnet <ip>
      • login <username>
      • enter password
    • rlogin
      • rlogin <ip> -l <username>
      • enter password
    RLOGIN SSH TELNET
  • Testing SNMP Credential
    • Test from the Appliance CLI as the user ‘tideway’
    • SNMP
      • snmpwalk -On -v2c -c <string> <ip> .1.3.6.1.2.1.1.1.0
    • Expected Return
      • .1.3.6.1.2.1.1.1.0 = STRING: Linux linuxdisc 2.6.5-1.358smp #1 SMP Sat May 8 09:25:36 EDT 2004 i686
    SNMP
  • Testing Windows Credential (1)
    • Test from the Slave Host as the service user
      • 1) Start wbemtest from Start -> Run -> wbemtest
      • 2) Click on the “Connect…” button top right
    WMI
  • Testing Windows Credential (2)
      • 3) In the connect window that pops up replace the field “ rootdefault ” with “ <target-machine>rootcimv2 ”
      • 4) Enter valid credentials for the target machine in the User and Password fields
      • 5) Click “Connect”
      • There should be a short delay while wbemtest connects. You should return to the main wbemtest window with all the buttons enabled
    WMI
  • Testing Windows Credential (3)
      • This confirms remote WMI access is possible, but to confirm we will query Win32_ComputerSystem
      • 6) Click “Open Class..”
      • 7) In the Get Class Name window that pops up enter “Win32_ComputerSystem” and click OK
      • This should return an object editor window
    WMI
  • Testing Windows Credential (4)
      • 8) Click on “Instances” which should return a single instance with the name of the target machine
      • 9) Double click the instance to get an Object editor window for that instance and confirm that Domain, Name, Manufacturer and Model are populated
    WMI
  • Further Resources
    • Online Documentation:
      • http://www.tideway.com/confluence/display/81/Credentials
    Tideway Foundation Version 7.2 Documentation Title