I have a requirement where I have to bind MS SQL server users with LDAP (openDJ). Currently I am seeing only option to achieve this is to have AD on SQL server and connect AD with openIDM through LDAP connector.
Is there a way this can be achieved through openAM and openDJ itself, without requiring openIDM in between.
Can you use Pass Through Authentication of OpenDJ?
https://backstage.forgerock.com/docs/opendj/2.6/admin-guide/chap-pta
https://wikis.forgerock.org/confluence/display/OPENDJ/Pass-Through+Authentication
Or JDBC Authentication Module of OpenAM?
https://backstage.forgerock.com/docs/openam/13.5/admin-guide/chap-auth-services#jdbc-module-conf-hints
I got to know that there is no way to achieve this.
I ended up using AD as the primary Directory store as password sync of users from DJ to AD (via IDM in between) was not possible. As the AD connectors available allow the flow of changes from AD to IDM/DJ only.
Related
I've got an Azure App Service that needs access to a classic SQL Server (non-Azure SQL, not SQL Managed Instance) and I'd prefer to do this via System Managed Identity. This is enabled on the App Service and a corresponding Enterprise Application is created on Azure AD.
The SQL Server is also connected to this Azure AD and User accounts on the AD already have access to the database. However I can't find how to create a login for the Enterprise Application. If this was an Azure SQL database I could do it with CREATE LOGIN [AZUREAD\app] FROM EXTERNAL PROVIDER but this does not work on a classic SQL Server, only on Azure SQL/MI.
A solution would be to use SQL accounts and reference the login/password in the connection strings, but as mentioned I'd much rather use Azure AD for authentication.
To answer my own question: SQL Server 2022 includes Azure AD authentication Link
Using integrated security or an access token it will be possible to authenticate with an App Registration.
This is currently in preview with no RTM date specified.
I'm quite new to the Azure AD. So I will be grateful for any hint.
I need to enable members of a given domain (of a given Active Directory) to log in to Azure SQL Server using Azure Active Directory - Integrated Authentication.
So far I've logged into Windows and connected it to Azure Acticve Directory in Windows Setting.
Looking through the documentation, I understand that I need to select one of the authentication methods proposed by Microsoft within Azure Active Directory. The easiest seems to be Password hash synchronization. So I would like to pick this one (But if others are simpliest I am open to change that choice)
What is the easiest way to synchronise this? Can I avoid having to create a Windows Server VM and install Azure AD Connect there?
The current configuration of AD Connect on Azure Portal looks as follows:
To mention it again, the only service I care about is logging in via Azure Active Directory
I apologise if the whole question has been wrongly structured, but it is simply based on what I have found on the forums and in the documentation.
Thanks in advance for any tips
[for example: https://youtu.be/PyeAC85Gm7w?t=565, https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-configure?tabs=azure-powershell#using-an-azure-ad-identity-to-connect-using-ssms-or-ssdt, https://techcommunity.microsoft.com/t5/azure-sql-blog/azure-ad-pass-through-and-password-hash-authentication-support/ba-p/1269735]
You don't need Azure AD Connect or password hash sync unless you have an on-premise Windows Server AD that you want to sync to Azure AD. Should note that AD is not the same as Azure AD. You don't need Windows Server AD with Azure SQL, just Azure AD. To grant a certain security group access to the server, you can run CREATE USER [group-name-here] FROM EXTERNAL PROVIDER; in the Azure SQL DB. Then you can use standard SQL stuff to grant that "user" access to the DB/tables.
Users should then use Azure Active Directory - Universal with MFA as the authentication method in SQL Server Management Studio.
I have many PG servers using LDAP authentication.
When I got request for new user, I create user account in every PG server so that LDAP can be used for authentication.
But, I wonder is there better way to manage accounts.
Why don't you implement one LDAP-Server as central authentication provider?
We're using MicroStrategy on-premises to access a warehouse in Snowflake. All the users connecting to Snowflake are authenticated through Azure AD. We want the same for MicroStrategy instead of using a local Snowflake account.
Is that possible?
Right now, when a user wants to connect through ODBC, we set up the Authenticator = ExternalBrowser. So when they use any software, the browser pops up for the authentication and then they continue to do their thing.
How can I set the ODBC of the MicroStrategy server to use the Azure AD authentication, without using the browser and by specifying the username we created for MicroStrategy in our AD.
Thanks,
JFS.
This likely requires you to configure MicroStrategy, Snowflake, and Azure AD to leverage OAuth2.
MicroStrategy has a how to guide here:
https://www2.microstrategy.com/producthelp/current/Gateway_Connections/WebHelp/Lang_1033/Content/integrate_sso_using_azure_for_snowflake.htm
We have got Windows Server with AD on premis, and we would like to have access to this AD (by ldap) from App Service hosted in Azure.
It is possible by using Hybrid Connection?
I've read somewhere that Hybrid Connections are based only on TCP, and the LDAP uses UDP (sometimes?).
The App service has code that connect on LDAP and query AD by LDAP.
It is possible there are some workarounds?
Hybrid connection isn't used in this manner. It utilizes an agent that's installed on an on-prem server that establishes a relay connection. This connection allows the app service to connect to your SQL server as if it were hosted in the cloud.
I think what you may want to look at is something like AD Connect which allows you to do hybrid identity and sync your on-prem AD with Azure AD. You can learn more about AD Connect architecture here but I don't know if what sort of protocol/connection it uses to do the sync. That may be dependent on the method of sync you choose.
After you've synced, the users should be in your AAD tenant in which you can leverage the Microsoft Graph API to read group permissions.