To anyone who has used SSH long enough the above message should look familiar. Everytime a user logs into a host via SSH that hosts unique host key is stored in the users ~/.ssh/known_hosts file. If a host is not already added into this file than the first occurrence of an SSH connection will display the above message, prompting the user to either enter yes or no. By entering Yes, the servers unique host key is automatically stored into the known_hosts file, this has been implemented to prevent man in the middle attacks.

Since servers are practically dispensable these days, they are provisioned and re-provisioned at the click of a button. It is quite common for a script to perform a remote SSH login on a new system to run commands. If this script is being run by an automated process, being asked a question may prevent the script from executing.

To get around this you can disable this feature, called StrictHostKeyChecking

Disable StrictHostKeyChecking System Wide:


StrictHostKeyChecking can be disabled on both the system as a whole or on a per user basis. To disable this setting on the system simply modify the /etc/ssh/ssh_config file.

# vi /etc/ssh/ssh_config

Search For:

# StrictHostKeyChecking ask

Replace with:

#StrictHostKeyChecking no

Disabling the KnownHostsFile:

If a host key is already added to the known_hosts file but does not match the host key being presented to SSH on login, the login will still fail. This would prevent logging into a host that shares the same hostname/IP as a previously provisioned host.

To prevent this scenario from stopping your automated script you can also change the KnownHostsFile to /dev/null. Thus preventing the host key from being added to any real file.

# vi ~/.ssh/config

Append

#UserKnownHostsFile /dev/null

Thank you for reading :)


In second post we have learned about, ServiceNow SAML 2.0 Settings and In this post we will discuss about ADFS Relying Party Configuration and ADFS Relying Party Claim Rules

ADFS Relying Party Configuration:

Now we take the Service-Now Metadata and import it into your ADFS server. However, manual configuration of the Relying partner appears to be easier to implement

1. Open the ADFS 2.0 Management console and select “Relying Party Trusts"
2. Select “add Relaying party Trust” from the top right corner of the window. The add wizard will   appear. Click on “Start” to begin
3. Select “Enter data about the relying party manually” and select “Next >”
4. Give it a display name such as “anyname” and enter any notes you wish finished by selecting “Next >”.
5. Select AD FS 2.0 Profile and click “Next >”.
6. Do not select anything and click "Next>"
7. Do not enable any settings on the “Configure URL” and press “Next >”.
8. Enter the Service-Now website you connect to as the Relying Party trust identifier. In this case use ‘https://companyname.service-now.com and click on “Add” and then click “Next >”.
9. Permit all users to access this relying party and select “Next >”.
10.Click “Next >” on the Ready to add page and uncheck “Open the Claims when this finishes” then close. You should now know see the Relying Party in the window.
11. Right click on the Relying Party trust and select “Properties”.
12. Browse to the “Endpoints tab” and add a “SAML Assertion Consumer” with a “Post” binding and a URL of https://companyname.service-now.com/navpage.do.

AD FS Relying Party Claim Rules:

Now is the time to edit the Claim rules in order to enable proper communication with Service-Now.

  1. Right click on the Relying Party and select “Edit Claim Rules…”
  2. On the Issuance Transform Rules tab select “Add Rules…”
  3. Select “Send LDAP Attribute as Claims” as the claim rule template to use and select “Next >”.
      Give the Claim a name such as “Get LDAP Attributes”. Attribute Store should be set to “Active  Directory” and LDAP Attribute should be “E-Mail-Addresses” and the Outgoing Claim Type should be NameID.
4. Click finish and Apply and OK

Add User to Active Directory:

1. Click start and Select Active Directory Users and Computers
2. Navigate to Users tab and Right click-->New-->User
3. Input FirstName and LastName and UserLogon Name(kiran@sample.com) 
4. Click Next and Input Password and Select Password never expires
5. Copy the user logon address
6. Click finish and Double click on User 
7. Past the copied Logon email address in email field
8. Apply and Click ok

Create a user in ServiceNow Instance:

1. Log on to your ServiceNow instance
2. Application Navigation->Systems and Security->Click Users 
3. Click on New button and Create a new user and Input email address copied earlier(kiran@sample.com)
4. Save

Testing:

1. Hit ADFS logon URL(https://your adfs domain/adfs/ls/idpinitiatedsignon.aspx)
2. Select your Relaying party and Proceed
3. Input ADFS user credentials and Proceed
4. You should be able to logon to ServiceNow

-------------------------------------------------------------------------------------------------------------------

  


     
 

 

 
In first post we have learned about collecting Federation Service Identifier and Export the “Token-Signing” certificate from microsoft's active directory federation server (adfs). In this post we will look at ServiceNow SAML 2.0 Settings

ServiceNow SAML 2.0 Settings:

1. Log into Service-Now with Admin privileges
2. Browse to “SAML 2 Single Sign On” and select Properties from application Navigator section

Note:
If SAML 2 is not listed, you will need to contact Service-Now from Hi portal to have it enabled 



3. The correct settings for this example explain below

Identity Provider properties:

#The Identity Provider URL which will issue the SAML2 security token with user info.
We have to place Identity Provider URL which collected earlier. Please refer article 1
Example: http://domain/adfs/services/trust

#The base URL to the Identity Provider's AuthnRequest service. The AuthnRequest will be posted to this URL as the SAMLRequest parameter

We have to place The base URL to the Identity Provider's
Example: ht/tp://domain/adfs/services/trust/ls

#Sign AuthnRequest.

Leave default

#The base URL to the Identity Provider's SingleLogoutRequest service. The LogoutRequest will be posted to this URL as the SAMLRequest parameter

Based on the URL specified logout request will be redirected
Example:Idp login(https://domain/adfs/ls/idpinitiatedsignon.aspx)
 
#The protocol binding for the Identity Provider's SingleLogoutRequest service. (Value can be either "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" or "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST".)

Leave default

#Sign LogoutRequest. Set this property to true if the Identity Provider's SingleLogoutRequest service requires signed LogoutRequest.

Leave default

#When SAML 2.0 single sign-on fails because the session is not authenticated, or this is the first login, redirect to this URL. This is the base URL where the initial SAML 2.0 AuthnRequest is sent using the SAMLRequest parameter

Leave default

#URL to redirect users after logout, typically back to the portal that enabled the SSO (e.g. http://portal.companya.com/logout)

Leave default
  

Service Provider (Service-Now) properties:

#The URL to the Service-now instance homepage.

This is Servicenow Login URL
Example:https://demo.service-now.com/navpage.do

#The entity identification, or the issuer

Example: https://demo.service-now.com

#The audience uri that accepts SAML2 token. (Normally, it is your instance URI

Example: https://demo.service-now.com

#The User table field to match with the Subject's NameID element in the SAMLResponse

This specifies the field in users table, that will be used to match the subject NameID in SAML assertion from Idp with ServiceNow user table
Example: email

#The NameID policy to use for returning the Subject's NameID in the SAMLResponse. Your SAML identity provider will have to support this by declaring the policy in its metadata. The NameID value is used to match with the specified field in the User table to lookup the user

Leave default 

#Create an AuthnContextClass request in the AuthnRequest statement.
This tells the IdP that ServiceNow requires that they present a specific login mechanism such as a form, Kerberos, etc. If the AuthnRequest doesn't specify an AuthnContextClass, the IdP will choose the most appropriate method.

Check Yes 

#The AuthnContextClassRef method that we will be included in our SAML 2.0 AuthnRequest to the Identity Provider

Leave Default

#The alias of key entry stored in SAML 2.0 SP Keystore used to sign SAML 2 requests.

Leave default

#The password of key entry stored in SAML 2.0 SP Keystore used to sign SAML 2 requests. 

Leave default

#Click SAVE

Certificate Settings: 

1. Select the  “Certificate” page from the application navigation. At the top right corner, 
2. Select the paper clip and attach the PEM certificate we created earlier. 




Sometimes the certificate’s fields such as Issue and Subject do not populate after selecting save and there may be an error on the top of the page. If this is the case, open the saves PEM formatted certificate in notepad and copy and paste the certificate in the “PEM Certificate:” field followed by clicking on “Update”. This page should have all the areas filled out.

------------------------------------------------------------------------------------------------------

In next post, we will discuss about  AD FS Relying Party Configuration and AD FS Relying Party Claim Rules
 
 



Service Provider:

A service provider (SP) is a company that provides organizations with enterprise class products like 
ServiceNow, Salesforce, Netsuite,etc.  Service can be storage, application, infra. 

SP  Initiated Single Sign On :

In this scenario a user attempts to access a protected resource directly on an SP Web site without being logged on 

Technical Flow:

In this scenario a user attempts to access a protected resource directly on an SP Web site without being logged on. The user does not have an account on the SP site, but does have a federated account managed by a third-party IdP. The SP sends an authentication request to the IdP. Both the request and the returned SAML assertion are sent through the user’s browser via HTTP POST


 1.The user requests access to a protected SP resource. The request is redirected to the federation server to handle authentication.
2.The federation server sends an HTML form back to the browser with a SAML request for authentication from the IdP. The HTML form is automatically posted to the IdP’s SSO service.
3.If the user is not already logged on to the IdP site or if re-authentication is required, the IdP asks for credentials (e.g., ID and password) and the user logs on.
4.Additional information about the user may be retrieved from the user data store for inclusion in the SAML response. (These attributes are predetermined as part of the federation agreement between the IdP and the SP—see About Attributes in the PingFederate Administrator’s Manual.)
5.The IdP’s SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP.
NOTE:SAML specifications require that POST responses be digitally signed.
6.If the signature and assertion are valid, the SP establishes a session for the user and redirects the browser to the target resource.








Identity Provider


 A system that creates, maintains, and manages identity information.

IdP (Identity Provider), is a system that creates, maintains, and manages identity information for principals (users, services, or systems) and provides principal authentication to other service providers (applications) within a federation or distributed network. It is a trusted third party that can be relied upon by users and servers when users and servers are establishing a dialog that must be authenticated. The IdP sends an attribute assertion containing trusted information about the user to the SP

We are going to use Identity Provider Initiated SSO in later article. Means User will Login from Outside(IDp) and will be redirected to ServiceNow/Salesforce. Identity Provider must follow Federated Authentication (SAML) standard

SAML stands for “Security Assertion Markup Language” and it is Open standard for exchanging Authentication and Authorization between Systems. SAML based authentication is supported both
ServiceNow/Salesforce

Idp  Initiated Single Sign On : 

In IDp Initiated SSO, User Directly logins to Identity provider/Idp redirects user to proper ServiceNow/Salesforce Instance with SAML assertion in request (Service Provider). If SAML assertion is valid then Salesforce validates that user successfuly.

Technical Flow: 

In this scenario, a user is logged on to the IdP and attempts to access a resource on a remote SP server. The SAML assertion is transported to the SP via HTTP POST.

 


Processing Steps:
  • A user has logged on to the IdP.
  • The user requests access to a protected SP resource. The user is not logged on to the SP site.
  • Optionally, the IdP retrieves attributes from the user data store.
  • The IdP’s SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP.
  • NOTE:SAML specifications require that POST responses be digitally signed.
  • If the signature and assertion are valid, the SP establishes a session for the user and redirects the browser to the target resource.

 









Hello Friends,

In this series, We will be discussing about single sign on(SSO) and Types of SSO  and We will discuss about underlying architecture.

Single Sign on(SSO):

Single Sign On (SSO) is a process that allow a user to access multiple services by logging in or  authenticate only once. This involves authentication into all services the user has given permission to, after logging into a Identity provider(Ex: ADFS).

The basic process of SSO is as follows:

  1. The first step is logging into the main service(Ex, Idp) 
  2. The user requests access to a protected SP(Salesforce, ServiceNow, etc) resource 
  3. Idp  verifies user authorization with the help of attributes from the user data store
  4. Based on that Idp generate SAML response containing the authentication assertion and any additional attributes
  5. Based on SAML response, Idp will redirect you to the protected service provider
A good example of the use of SSO is in Google’s services. You need only be signed in to one primary Google account to access different services like YouTube, Gmail, Google+, Google Analytics, and more.

Advantages of SSO:

  1. No need to manage large numbers of passwords. 
  2. A simpler sign-up and login process, which can also be good for conversions. 
  3. Reduced exposure to the risks of data loss. Users already trust the identity provider 
  4. etc 


Single Sign-On access to ServiceNow  the following configurations:

1. Configurations in the ServiceNow  to accept secure communication from IdP.

2. Configurations in Identity Provider to accept communication from the ServiceNow.

Prerequisite:

  • ServiceNow Instance
  • SAML 2 Single sign on plugin
  • Microsoft's active directory federation server (adfs)(Idp)
Note: SAML 2 Single sign on plugin is a on demand service , we have to put a request via " ServiceNow Hi"   portal to enable it. You will below configuration from ServiceNow application
Navigation section


SSO Configuration with ADFS Involves in Following Steps:

  • Get Federation Service Identifier
  • ServiceNow SAML 2.0 Settings
  • AD FS Relying Party Configuration
  • AD FS Relying Party Claim Rules
  • Testing the setup

 Get Federation Service Identifier and Export the “Token-Signing” certificate: 

 Get Federation Service Identifier:

  • Log into your ADFS 2.0 server and open the management console
  • Right click on Service and choose Edit Federation Service Properties 
  • Copy the Federation Service Identifier as that will be used to enter into the Service-Now SAML 2.0 configuration settings
Note: Please update your local host entries if  Federation Service Identifier domain is not public

Export the “Token-Signing” certificate: 


    1.Right click on Service and Double click on certificates
    2.Double click on Token-signing from certificate section
    3.Certificate wizard will open
    4.Click on the “Details” tab
    5.Click on “Copy to File…” The Certificate Export Wizard will launch. and Select “Next >”
    6.Ensure “No, do not export the private key” is select and press “Next >”
    7.Select “DER encoded binary X.509 (.cer)” and press “Next >”
    8.Select where you want to save the file and give it a name and press “Next >”.
    9.Finally, select “Finish”
 

    Note:

    Service-now requires that this certificate be in PEM format. You can convert this certificate using client tools or even online tools such as: SSL Shopper. Use the DER/Binary certificate we just created and export it to “Standard PEM” format.

    SSL Shopper:

        1.Login to https://www.sslshopper.com/ssl-converter.html
        2.Choose DER encoded binary X.509 (.cer)



     

        3.Select DER/Binary for Type of current certificate
        4.Select Standard PEM for Type To Convert To
        5.Copy the PEM to Text editor
      As of now, we have collected  Federation Service Identifier and Exported the “Token-Signing” certificate and Copied PEM.

      ----------------------------------------------------------------------------------------------------------------
       In next post will discuss about setting up ServiceNow SAML 2.0 Settings. Stay tune











      AIDE:

      AIDE (Advanced Intrusion Detection Environment) is a file and directory integrity checker

      It creates a database from the regular expression rules that it finds from the config file(s). Once this database is initialized it can be used to verify the integrity of the files. It has several message digest algorithms (see below) that are used to check the integrity of the file. All of the usual file attributes can also be checked for inconsistencies.

      Installation Procedure:
      1. Install AIDE package on CentOS/RHEL:
      # yum install -y aide
      2. Check and adjust aide configuration file to fulfill your needs:
      # vim /etc/aide.conf
      3. Initialize AIDE database - it will scan all the files in folders that were included in the config file and save their hash as well as attributes info
      aide --init
      Once initialized we may see below line
      ### AIDE database at /var/lib/aide/aide.db.new.gz initialized.
      4. we need to modify newly created database with mv command
      mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz


      5. Check the database before making any changes
      aide --check
      6. Make any changes Ex : touch /usr/sbin/mytestfile.txt(just relating any file to test)
      again check aide database fro notify changes by running below command
      aide --check


      7. You may consider keeping golden copy of AIDE database (default is set to /var/lib/aide/aide.db.gz) is secure and read-only location. It will allow you to compare current system integrity to the golden copy.
      To check what changed run:
      # aide -C



      A popular host-based intrusion detection system on Linux is tripwire. This software can keep track of many different filesystem data points in order to detect whether unauthorized changes have occurred.

      In this article, we will discuss how to install and configure tripwire and Commands for installation


      Install Tripwire.
      # yum install tripwire -y

      Creating site and local keyfile pass-phrases
      # tripwire-setup-keyfiles

      Initializing Tripwire Database
      # tripwire --init

      Modifying Tripwire policy file
      # vi /etc/tripwire/twpol.txt

      Once modifying all the files, update the tripwire policy file.
      # tripwire --update-policy --secure-mode low /etc/tripwire/twpol.txt

      Checking for any changes in files/directories
      # tripwire --check --interactive

      It will ask you to enter passwords

      Now let us add a new file called Anil.
      # touch Anil

      Now check this file with tripwire ?check ?interactive command. You may find the file Anil under the Added section in the result
      # tripwire --check --interactive

      OR

      # tripwire --check
      It will not ask you to enter password

      Viewing the tripwire report file
      All tripwire report files having extension .twr are stored in /var/lib/tripwire/report/ directory. These are not text files, so you can?t view them using any editor. First convert them using the following command to human readable format.
      # twprint --print-report --twrfile /var/lib/tripwire/report/server.ostechnix.com-20130510-124159.twr > /tmp/twrreport.txt

      Now open the file using any editor.
      # vi /tmp/twrreport.txt 

      Viewing tripwire configuration and policy file locations
      To view the policy file locations enter the following command.

      #twadmin --print-polfile

      To view the configuration files enter the following command.
      # twadmin --print-cfgfile

      Scheduling Tripwire Check
      You may find a cron file tripwire-check might be created automatically in the /etc/cron.daily/ directory. If it isn?t created, open your crontab file and add lines as shown below. The following example will execute the tripwire daily at 5 am.

      # vi /etc/crontab 
      # Tripwire Monitor process
      00 5 * * * /usr/sbin/tripwire  --check

      OR

      0 7 * * * /usr/sbin/tripwire --check > /mnt/tripwire
      0 8 * * * /bin/mail -s "Tripwire" amullapudi@ciphercloud.com  < /tmp/tripwire

      It will check system at 7 AM of everyday,everyweek,every month,every year and it will send an email on same.

      ========================================================================