Root credentials for Latest Kali Linux [ver 2020.1 & later]

Kali had changed to a non-root user policy by default since the release of 2020.1.Which means, the old  root/toor credentials won't work by default.

When some one login to the Kali linux using the new default credentials kali/kali , they wont be having the root privileges. Even unable to view the IP Address using the ifconfig command.

So the command not found, due to the lack of privileges.

To solve this, you can run the command in sudo.

#sudo ifconfig will give you the result. But executing all commands with sudo is bit inconvenience.

So let''s activate the root user.

#sudo su

and then reset the password using #passwd root

Enter your new password for the root user.

Restart Kali or switch user, and then login with root and the new password that you've set.

Read More

Nutanix .NEXT Conference and Free certification.

Good news to all NCP/NCAP/NCSE aspirants. Nutanix Global .NEXT event, happening September 8th – September 10th, 2020. All .NEXT attendees will receive a voucher to take the NCP, NCAP, or NCSE exams for FREE through October 15.
 
 Registration link : https://www.nutanix.com/next/register.html
 Explore more : https://next.nutanix.com/education-blog-78/training-and-certification-programs-at-the-global-next-digital-experience-37850

Read More

Azure Cloud Security # Consolidated Notes and Documentations.

Consolidated list of documentations and tutorials related to Microsoft Azure Cloud Security. Can be used to perform a deep dive on Azure security and for the preparation of Azure Security certification.

Feel free to share. Happy learning.

Preparation Notes

• Mizrosoft Azure Services #Index

• Scaling Up/Vertical Scaling vs Scaling Out/Horizontal Scaling.

• What are Azure availability sets?

• Difference between Azure management groups, Subscriptions and Resource groups

• Azure Active Directory : Overview.
  

• Azure Active Directory User Types and RBAC built-in roles
  

• Azure Active Directory User Source of Authority (SoA)
  

• Application Registration in Azure Active Directory
  

• Azure Active Directory Identity Protection.

• Azure AD Connect Overview.

• Azure Front Door : Overview.

• Hardening your Azure cloud platform and best practices.

Security Documentation Glossary.

• Azure Well-Architected Framework
• Introduction to Azure security
• Azure security documentation
• Using customer-managed keys in Azure Key Vault with Storage Service Encryption
• Start using Azure Active Directory Privileged Identity Management
  
• Privileged Identity Management documentation
  
• What is Azure Security Center?
  
• Azure Security Center documentation
  
• What is Conditional Access?
• Microsoft Security Development Life-cycle
  
• Azure Information Protection documentation
• Azure Sentinel documentation
  
• Azure Key Vault
• Azure Security Center for IoT documentation
• Azure Dedicated HSM documentation
• Azure DDoS Protection Standard overview
• Microsoft security architecture recommendations
• Become an Azure Sentinel Ninja: The complete level 400 training

Read More

Azure Front Door : Overview #CloudScribblings

Azure Front Door is a combination of Load-balancer and Web Application Firewall (WAF). It is a routing service that helps to accelerate the application access availability and performance and works at the Application layer.

Azure Front Door service can be considered when you have a pool of application servers at the back-end and you need to load-balance the client requests and enhance the security. When you implement this service, it will route the client requests to the fastest and most available application back-end. These requests can be distributed to the back-end pool based on Weight-age and Priority.

Azure Front Door service features,

1) URL based routing

2) Maintaining session affinity

3) SSL termination

4) Web Application Firewall Features.

You can configure Azure Front Door in three steps.

Search Front Door service from your Azure dashboard.

1) Add the front-end hosts / Domain name.

• Configure the front-end URL. User requests will hit here. You can enable affinity and WAF at this section.

2) Configure the Back-end pool

• Here you need to add all the back-end applications or app servers/endpoints.
• Once you add the applications, you need to configure the health probes as well.
• Priority and Weight-age for the endpoints can be configured here

3) Routing rules

• In this part, you maps the front-end host and a matching URL path pattern to a specific back-end pool. Same as a load-balancing rule.

More on Azure Cloud

Read More

Azure Active Directory : Overview #CloudScribblings

Azure Active Directory is an Identity store in the Cloud. You can create users,groups and service principles in the Azure AD. When you create an Azure account, an Azure AD directory is automatically created by default. You mention all your identities in the directory and is used to authenticate and authorize the users to access a resource in the Azure Cloud. If you want to drill-down the access permission, then you can make use of Role Based Access Control (RBAC) which is different from the Azure AD roles.Using Azure AD, you can enable a lot of security features for authentication & authorization such as Multi-Factor Authentication (MFA), Conditional Access, Privileged Identity Management (PIM) etc.

When it comes to billing, Azure AD is different from your Subscription billing. Normally all your resource usage will be billed against your subscription. But for Azure AD, you need to purchase the license separately from Microsoft Office 365 portal using a Work/school account. The license are classified in to 4. Free,Office 365 apps,Premium P1,Premium P2. The Free AD subscription doesn't have an SLA attached. And if you want to make use of Conditional Access with MFA, PIM & Identity Governance, then you much go with Premium P2 license. To purchase a license, requires a Global Administrator account joined to your own custom domain. Using that account, login and purchase the license from the Microsoft Office portal. Once you purchased the license, you have to manually assign the license to the AD users to make use of the features. However you can perform this dynamically as well.

An important thing to note is, An Azure AD is just an Identity Store and you cannot join devices like you perform on your legacy on-premises MS AD server. Azure AD doesn't support LDAP or Kerberos. If you want to implement a proper Active Directory, then you need to spin up an Active Directory server on a Windows Virtual Machine. Also there is a separate Managed service from Azure, which is Azure Active Directory Domain Services (AD DS), enables to join your Azure Virtual Machines to the domain. In this case, you don't need to manage the domain controller manually.

Azure Active Directory has two types of Users.

1) Member
A member is a normal cloud user. An Active Directory member can read all directory information and can invite external users. They can also manage their own profile information and can register applications in the AD.
2) Guest
Restricted user  who can manage only their own profile data. Cannot browse the directory and cannot register applications in the AD.

More on Azure Cloud

Read More

Azure AD Connect Overview #CloudScribblings

The Azure AD Connect synchronization service is used to synchronize identity data between your on-premise environment and Azure Active Directory.
There are two components for this service

• Azure AD Connect sync component – This is installed on the on-premise environment, recommended to be installed on a domain joined separate server and not on AD server directly.
• Azure AD Connect sync service – This service runs in Azure AD.

Prerequisites for Configuring the Azure AD connect.

• An Azure AD tenant
• You need to add and verify your domain in Azure AD
• The Azure AD Connect sync component must be installed on a Windows Server 2012 Standard or later (On-Premises). The server must have the full GUI installed. The server must be domain joined.Recommended no to install in the AD DC server directly.

The Azure AD Connect sync component requires a SQL Server database for storing identity data. By default , the installation of Azure AD Connect will install SQL Server 2012 Express LocalDB.During the configuration of the Azure AD Connect sync component, you need to use the following accounts and permissions.

• Azure AD Global Administrator account for the Azure AD tenant. The account should be a school or organization account and cannot be a Microsoft account
• An Enterprise Administrator account for the on-premise Active Directory
• The Azure AD Connect server needs DNS resolution for both intranet and internet. The DNS server must be able to resolve names both to your on-premises Active Directory and the Azure AD endpoints. When a user try to authenticate, the sign in page will be redirected to the On-Premises URL, based on your configuration.

There are two methods to connect your on-premise AD with the Azure AD.
Password Hash Synchronization
Here Azure AD Connect synchronizes a hash, of the hash, of a users password from an on-premises Active Directory instance to a cloud-based Azure AD instance.
The advantage is that you only need to maintain one password for both authentication in your on-premise environments and in the cloud.If a user change his/her password on the On-premise AD, the password will be synced onto Azure AD. But the reverse will not happen.
Pass-through Authentication
This is kind of similar to password hash synchronization, but here the users’ passwords is directly validated against the on-premise Active Directory. Means, when a user try to authenticate, the authentication request will be sent to the on-premise Active directory.
Password Write-Back
Password write-back is a feature enabled with Azure AD Connect that allows password changes in the cloud to be written back to an existing on-premises directory in real time. In this configuration, as users change or reset their passwords using Self Service Password Reset (SSPR) in the cloud, the updated passwords also written back to the on-premises AD DS environment. This can be configured along with Password Hash Synchronization & Pass-through Authentication if required.

Read More

Azure Active Directory Identity Protection #CloudScribblings

Azure Active Directory Identity Protection is used to ,

1. Automate the detection of any identity-based risks.
   
2. It can also be used to investigate any risks to using reports data in the portal
3. It can be used to expose risk detection data to third-party utilities for further analysis.
4. Also possible to auto remediate the risks
   

To use this feature fully fledged, Azure AD Premium P2 license is required.
The tool can detect the following risk factors,
Leaked credentials - If a user's credentials are leaked , AD Identity protection can get the intelligence and block the access.
Sign-ins from anonymous IP addresses - These are user sign-ins that are originated from an IP address that has been identified as an anonymous proxy IP address or VPN.
Logins from atypical locations - User sign-in occurs from geographically distant locations, where at least one of the locations may also be atypical for the user. For example, the user is login from New York and in the next hour another login request from New Delhi (Which is impossible to travel in one hour) for the same user.
Sign-in from unfamiliar locations - This processes uses the prior sign-ins of the user to detect unusual locations for new sign-ins from the user.
Sign-ins from infected devices/IP - Identifies any sign-ins that happens from devices infected with malware or Malware related IP Addresses.
Sign-ins from IP addresses with suspicious activity - Identifies the IP addresses from which a high number of failed sign-in attempts happens across multiple user accounts over a short period of time.

Read More

Application Registration in Azure Active Directory #CloudScribblings

When you register an application in Azure AD , you need to specify the application details and the permission details that the application should have when it access the Azure Services.
The application can authenticate through the Microsoft Identity platform. The Microsoft Identity platform uses OAuth 2.0 authorization service that enables a third-party application to access web-hosted resources. Once the application object is registered in Azure AD, it is called as a service principle.
When you register an application in Azure AD, you need to keep note of two things.
1) Application or Client Identity.
2) Directory or Tenant ID.

These ID's are automatically generated during the application registration. Normally, these two information are required to be specified at the application end.
After the registration, you may required to generate a client secret and that can be done from the AD -> Certificates & Secrets section. Note that once the secret is generated, you must copy the code somewhere secure (for example, your key vault). The moment you leaves the Certificates & Secrets page, you won't be able to see the generated secret again.
The final things that you may need to perform during the application registration process is, Configuring the API permission. (Under AD-> API permissions)
The Microsoft Identity platform supports the following permission types
Delegated permissions - Use this option when the applications have a signed-in user. The application is then delegated permissions to act on behalf of the signed-in user to make calls to a target resource.
Application permissions - These are applications that run without a signed-in user.

Finally, Grant Admin consent after creating the permission.

These are the major tasks that's needs to be performed in the Azure cloud, for registering an application in Azure Active Directory.

Read More

Azure Active Directory User Source of Authority (SoA) #cloudscribblings

Source of Authority (SoA) describes where the user is primarily defined. This can be classified in to four categories. A user can be defined in,

1) Azure Active Directory
This is a native cloud user account also known a member.
2) External Azure Active Directory
Invited user from another azure tenant. If you invite a user from another tenant to your tenant, the user's SoA will be External Azure Active Directory.
3) Microsoft Account
A person who creates the subscription (Subscription owner) with a Microsoft account (live, hotmail etc) will have the SoA of Microsoft Account.
4) Local Active Directory
Synchronized user accounts with an on-premises Active directory will have the SoA of Local Active Directory.

Read More

Azure Active Directory User Types and RBAC built-in roles #CloudScribblings

Azure Active Directory has two types of Users.

1) Member
A member is a normal cloud user. An Active Directory member can read all directory information and can invite external users. They can also manage their own profile information and can register applications in the AD.
2) Guest

Restricted user  who can manage only their own profile data. Cannot browse the directory and cannot register applications in the AD.

RBAC built-in roles (Top 4)

1. Owner Role : Lets you manage everything, including access to resources.The owner can add permission, perform actions such as delete, stop the resources.
2. Contributor Role : This role allows a user to manage all types of resources, but does not allow the user to grant access to resources.To allow a user to have the ability to grant access to resources, the user must be assigned with either the User Access Administrator Role or the Owner Role
3. User Access Administrator Role : In this role, the user can manage the access to resources. The user would be able to read all resources, but can't modify.
4. Virtual Machine Contributor Role : This allows to manage the properties of the Virtual Machine. This will not provide access to the underlying virtual network or the storage accounts the virtual machine is connected to.

Read More