Monday, April 8, 2024

Cross-Platform Efficiency: Mastering Federation of Azure AD with OCI Identity Domains for SSO Solution

 By federating Azure AD with OCI Identity domains(more on OCI Identity Domains), businesses can centralize user authentication, simplifying access management and reducing administrative overhead. This robust integration enables a single sign-on (SSO) experience, allowing users to securely access resources across both platforms with a single set of credentials. With enhanced security measures and simplified user provisioning, organizations can ensure compliance with regulatory standards while fostering a seamless user experience. Now, with all new tenancies, Oracle has introduced identity domains as a single domain for storing all the users, groups credentials and so the navigations have also changed a bit. Also, the point to be noted that in the background, it is the same IDCS solution running.

SSO between OCI and Azure


Here, OCI act as a service provider (SP) and Microsoft Azure act as an Identity Provider (IdP). The Service Provider (OCI) creates a SAML request and forwards the user and the SAML request to the Identity Provider (Azure AD). Once the user is authenticated, the IdP sends back a SAML response with an assertion to the Service Provider's Assertion Consumer Service endpoint. 

Note: Azure AD  is now Microsoft Entra ID.


Go to the OCI Hamburger menu > Identity and Security



Click on Domains and change the below settings first



get the IDCS url



Copy the IDCS url and add /fed/v1/metadata. Open a browser and save the file as XML.

On the Azure Portal now:-

Create an Enterprise Application. Choose the option as Oracle


Choose the option Oracle Cloud Infrastructure Console



Give it a name and Click on Create







Click on Single Sign on and choose the option for SAML







Upload the OCI downloaded metadata xml file



Download the Federation Metadata XML which has to be uploaded to OCI side.

OCI Side:-



Click on Add SAML IdP




Choose the option Upload metadata xml file




Upload the xml file downloaded from Azure Portal




Review and Create



Test the login



Activate the IdP




Edit the IdP policies and add Azure AD




Test the setup.

Note: User has to be present on both OCI IAM and Azure AD

Login to the OCI console and we will get the IdP icon




Click on Azure AD



oci login after federation



Here we are. We have successfully landed to the OCI home page.

This post explains about the integration of Oracle cloud Infrastructure Identity domains with Microsoft Azure AD for a seamless Single Sign on Solution.

I hope, this post will help someone. Till then, enjoy learning cloud.

References:-https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/federation.htm#top
https://docs.oracle.com/en-us/iaas/Content/Identity/tutorials/azure_ad/lifecycle_azure/02-config-azure-iam-template.htm#config-azure-iam-template

Thursday, April 4, 2024

Secure Your Network: Private DNS in Oracle Cloud Infrastructure

 Private DNS in Oracle Cloud Infrastructure (OCI) refers to a service that enables you to create and manage custom domain names within your virtual cloud network (VCN). With Private DNS, you can define custom domain names and map them to specific resources, such as Compute instances, Load Balancers, or other services within your VCN.

Key features and benefits of Private DNS in OCI include:
Custom Domain Names: You can create your own domain names, such as example.com or subdomain.example.com, tailored to your organization's needs.
Resource Mapping: Private DNS allows you to map these custom domain names to specific resources within your VCN, making it easier to manage and access your services.
Network Isolation: By using Private DNS within your VCN, you can ensure that your domain names remain private and are only accessible within your network, enhancing security and control.
Integration with Oracle Services: Private DNS seamlessly integrates with other Oracle Cloud services, enabling you to easily manage domain names for resources such as Compute instances, Load Balancers, and more.
Automation and Scalability: You can automate the creation and management of domain names using OCI's APIs, CLI, or Terraform, making it easy to scale and manage your infrastructure.
Overall, Private DNS in OCI provides a flexible and secure way to manage domain names and map them to resources within your virtual cloud network, facilitating efficient communication and management of your cloud infrastructure.
Now, the objective of this post is to give an idea on how we can communicate to the resources using their hostnames. As we know, DNS is a feature which translates hostnames to IP addresses. If we have resources in OCI and they don't know the respective hostnames, then the communication can't be established. To mitigate this problem, OCI has the option of Private DNS in OCI.
A small use case here.
When we provision a compute instance, it comes with its own fully qualified domain name example oraclevcn.com. Now, if i need to set it to samappsdba.com, we need to perform some additional steps.
The high level steps
Private DNS Zone – which contain DNS data from the VCN (like IP address)
Private DNS Views – this is collection of Zones, Zone can only belong to a single View.
Private DNS Resolver – you can assign Views to Resolver which will then resolve those DNS queries for you. Remember the order, first custom views, then default and finally from Internet




Once the A record is added and published, we can do the test




[opc@instance-20240328-1959 ~]$ host -t NS samapspdba.com

samapspdba.com name server vcn-dns.oraclevcn.com.

[opc@instance-20240328-1959 ~]$

 

After I delete it the private view

 

@instance-20240328-1959 ~]$ host -t NS samapspdba.com

samapspdba.com name server vcn-dns.oraclevcn.com.

[opc@instance-20240328-1959 ~]$ nslookup www.samapspdba.com

Server:         169.254.169.254

Address:        169.254.169.254#53

 

** server can't find www.samapspdba.com: REFUSED


This is a basic demonstration on how using private DNS feature in OCI, we can customize the hostname. 

I hope this post helps someone.






Tuesday, March 26, 2024

Read only access to OCI Console.

 If you need read-only access to the Oracle Cloud Infrastructure (OCI) Console, you can achieve this by creating a policy within OCI Identity and Access Management (IAM) that grants only the necessary read permissions to the resources you want to access. The below steps are applicable to identity domains only. To read more about identity domains identity domains in OCI



Here's a general outline of how you might set this up:

1. Create a User

2. Create a group and assign the above created user to group

3. Create a policy in root compartment

Verb:- allow group group_name to read all-resources in tenancy

Note:-Note* Please keep in mind that even though the above users created have only “Read-only” access, they will be able to click certain options such as “create, edit, reboot, terminate, etc”, however, they won’t be able to execute any of these options

Hope this post help someone

Friday, March 22, 2024

Hub and spoke using IP Masquerading in OCI aka Oracle Cloud Infrastructure

 In Oracle Cloud Infrastructure (OCI), the "hub and spoke" architecture is a common networking design used to connect multiple Virtual Cloud Networks (VCNs) in a centralized manner. This architecture is often implemented using Dynamic Routing Gateway (DRG) attachments and Transit Routing. Let me break down how it works:

Hub and Spoke



Hub VCN: In the hub-and-spoke model, one VCN serves as the central hub where shared services or resources are located. This hub VCN typically hosts core services such as DNS, Active Directory, or shared databases.

Spoke VCNs: Spoke VCNs are additional VCNs that are connected to the hub VCN. Each spoke VCN usually contains resources specific to a particular department, application, or environment.

Dynamic Routing Gateway (DRG): The DRG serves as the central routing hub for connecting the hub VCN to other VCNs or on-premises networks. It facilitates the exchange of routing information between the hub VCN and the spoke VCNs.

DRG Attachments: Each spoke VCN is connected to the hub VCN via a DRG attachment. A DRG attachment establishes a logical link between the spoke VCN and the DRG, enabling traffic to flow between them.

Transit Routing: Transit Routing is a feature in OCI that allows you to route traffic between different VCNs using the hub-and-spoke architecture. With Transit Routing, you can configure route tables in the hub VCN to direct traffic between spoke VCNs through the hub VCN.

Route Tables: Each VCN has its own route table that determines how traffic is routed within the VCN. In the hub-and-spoke model, route tables in the hub VCN are configured to route traffic between spoke VCNs.

Security: Security within the hub-and-spoke architecture is typically managed using Security Lists, Network Security Groups (NSGs), and other OCI security features. Access control can be enforced at the subnet level to restrict traffic between different environments.

By implementing a hub-and-spoke architecture using DRG attachments and Transit Routing in OCI, organizations can achieve centralized network management, simplified connectivity between VCNs, and improved security and compliance. This architecture is well-suited for scenarios where multiple VCNs need to communicate with each other while maintaining isolation and security boundaries.

Now, the objective of this post is to explain, how leveraging DRG attachments and VCN Route tables we can make the communication between hub and spoke. And also, using transit route, how we can enable the resources provisioned inside spoke VCN to reach the internet using Hub VCN.

 

Present Architecture:-

Present VCN


Hub:-

Subnet inside HUB


Spoke1 VCN:-

Subnet inside Spoke1 VCN


Spoke2 VCN:-

Subnet inside Spoke2 VCN


The security list at this moment has ingress from spoke1 vcn cidr to spoke2 and vice versa.

I will now try to ping spoke2 instance from spoke1.

As expected, it is not working


Ping result


Create a DRG:-
  


DRG



next, i am going to attach the 2 spokes



Now, under the route table for spokes VCN, we are going to add a new route

Route


Ping is now working on both the side of spokes

ping


The next requirement of this post, is that from spoke VCN, we want to reach to internet via Hub VCN. This will be done via transit route.


In the hub machine compute instance, i'll add a secondary vnic in the same subnet as primary vnic. The subnet is of public type and IGW is attached to it.

Secondary Vnic




Ethernet


Under DRG, create anew distribution list for hub-vcn attachment


DRG Route Distribution List


Create a new DRG route table for hub-vcn


DRG route table

 Attach the hub-vcn to DRG


VCN attachment

Now create a VCN DRG route table and point it to private IP address of secondary vnic


new Route


Add a security list for this public subnet to receive request from spoke VCNs.



Security list for the spoke VCN. Add a ingress rule to receive request from hub vcn




Add the transit route to DRG


transit route

Now, make the nating on the hub-vcn compute instance

sysctl -w net.ipv4.ip_forward=1

firewall-cmd --permanent --direct --add-rule ipv4 nat POSTROUTING 0 \

  -o enp0s6 -j MASQUERADE

 

[root@primary-vnic opc]# firewall-cmd --permanent --zone public --add-interface enp0s6

The interface is under control of NetworkManager, setting zone to 'public'.

success

[root@primary-vnic opc]# firewall-cmd --permanent --zone public --add-masquerade

 

[root@primary-vnic opc]# systemctl restart firewalld

[root@primary-vnic opc]# firewall-cmd --reload

success

[root@primary-vnic opc]#


sysctl -w net.ipv4.conf.all.rp_filter=2


added the route for secondary vnic

[root@primary-vnic opc]# ip route

default via 192.168.0.1 dev enp0s6

default via 192.168.0.1 dev enp0s6 proto dhcp src 192.168.0.49 metric 100

169.254.0.0/16 dev enp0s6 scope link

169.254.0.0/16 dev enp0s6 proto dhcp scope link src 192.168.0.49 metric 100

192.168.0.0/26 dev enp0s6 proto kernel scope link src 192.168.0.49

192.168.0.0/26 dev enp1s0 proto kernel scope link src 192.168.0.57

192.168.0.0/26 dev enp0s6 proto kernel scope link src 192.168.0.49 metric 100

[root@primary-vnic opc]# ip route add 10.10.0.0/26 via 192.168.0.1 dev enp1s0

 

10.10.0.0/26 is the CIDR for spoke1 private subnet

 

Now, if I try to ping google.com from spoke1 vcn




Through this post, i just wanted to show how using IP Masquerading feature we can reach to the internet from the spoke VCN private subnet. Also, how this can be achieved under Hub & Spoke Model. I hope this post will help someone.




Wednesday, January 17, 2024

connect to Compute instance on Private Subnet using another Compute instance

 There are many ways using which we can connect to a compute instance running on private subnet and having only private subnet. We can use OCI Bastion service, Secure shell and for enterprise level, we can leverage FastConnect & IPSecVPN. In my previous post Connect to private compute instance, i have shown, how we can connect to a compute instance running on private subnet using public load balancer. The objective of this post is to show, how we can connect to a compute instance running on private subnet using a compute instance running on public subnet in same VCN. This method is very helpful, wherein if we want to do some POCs and want to connect to private compute instance from our desktop machine locally. 


Steps:- I have a VCN named as TEST and inside that i have two subnets one is private and another one is public.




The public subnet has the default security list attached and default route table with Internet gateway enabled.  Next, i created two compute instance, one in public subnet and another one in private subnet.





Then, i will create a new security list for private subnet and edit the security list of private subnet and attach the new security list, which will have ingress from the private IP address of the public compute instance. I will also create a new route table with 0 rules under it and attach it to private subnet.


Security rule for private subnet

ingress:-

egress:-





Now, i will connect to the compute instance on public subnet using putty and i will place the public key in rsa format(for private subnet) in some directory



The rsa format has to be changed using puttygen



Now from the public instance, i should be able to connect to the private instance running on private subnet using its private IP



The above was just a basic way on how we can connect to the private compute instance running on public subnet. This should be helpful when we want to do some small POCs using our local machine.

I hope this post will help someone. Till then, happy learning cloud.