I have wso2 Identity server in my TEST environment. Team has been using it for some months and lot of users and roles are created. Recently we have got CA certificates and installed it. After that we cant add users saying the problem Error while encrypting the Credential for User Name. Looks like new certificate is the problem
1)I have my MySQL database in AWS Cloud. Could anything with the database cause problem?
2) If i clear all the tables for WSO2 , will WSO2 work again? If so , which are all the tables to clear.
Suggest any other solutions
Related
I am using .NET Core 2.0 and ASP.NET Core 2.0 for application development. The "test" application is a .NET Core Console application. The core code I am writing is a class library. Once proper testing. I choose to do this since I won't be putting this to use for awhile (it's replacing older ASPNET code).
Anyway, since I have to work with a LOT of API keys for various services I decided to use Microsoft Azure Key Vault for storing the keys. I have this all setup and understand how this works. The test application uses a test Azure account so it's not critical. And since this is replacing legacy code and it's in the infancy, I am the sole developer.
Basically, I'm running into this issue. There's not too much information on Azure Key Vault from what I can see. A lot of examples are storing the Client ID and Secret in a plain text json file (for example: https://www.humankode.com/asp-net-core/how-to-store-secrets-in-azure-key-vault-using-net-core). I really don't understand how this can be secure. If someone were to get those keys they could easily access stored information Azure, right?
The Microsoft MSDN has a powershell command that grants access (I lost the original link, this is closest I can find: https://www.red-gate.com/simple-talk/cloud/platform-as-a-service/setting-up-and-configuring-an-azure-key-vault/) My development operating system is Windows 10 and my primary server operating system is Debian.
How would I approach this?
Yes, you are right, the plain text config file could be used only during development, not for production purpose. And in general, available options depend on where and how you host an App.
If you have an Azure Web App, you have at least next built-in options (from the documentation):
add the ClientId and ClientSecret values for the AppSettings in the Azure portal. By doing this, the actual values will not be in the web.config but protected via the Portal where you have separate access control capabilities. These values will be substituted for the values that you entered in your web.config. Make sure that the names are the same.
authenticate an Azure AD application is by using a Client ID and a Certificate instead of a Client ID and Client Secret. Following are the steps to use a Certificate in an Azure Web App:
Get or Create a Certificate
Associate the Certificate with an Azure AD application
Add code to your Web App to use the Certificate
Add a Certificate to your Web App
You may also find an approach that uses env variables to store credentials. This may be OK only if you can guarantee that it's not possible to do a snapshot of env variable on prod machine. Look into Environment Variables Considered Harmful for Your Secrets for more details.
And the last one thing: there is also a technic that based on the idea, that you need to store/pass only a ClientSecret value while ClientId should be constructed based on machine/container details where the App is hosted (e.g. docker container id). I have found an example for Hashicorp Vault and an App hosted on AWS, but the general idea is the same: Secret management with Vault
In addition to the first answer, with the context of running applications on Azure VM, instead of using client_secret to authenticate, you can use client certificate authentication as explained in this documentation: Authenticate with a Certificate instead of a Client Secret.
In the picture above:
Application is authenticating to AAD by proving that it has the private key of the certificate (which is basically stored in CNG if you are using Windows).
Application get back the access_token and then use it to access the Key Vault.
The developer does not need to know the private key value of the certificate in order for their app to be successfully authenticated. Instead, they only need to know the location of the imported pfx (a container for private key and its certificate) in the Certificate Store.
At least on Windows, you as secret administrator can convert the private key and the certificate into pfx format which is password protected, and then deploy it into the Windows Certificate store. This way no one could know the private key unless they know the password of the pfx file.
The other approach specifics for Azure Compute, is to use Azure Managed Service Identity. Using Azure MSI, Azure will automatically assign your resources such as VM with an identity / Service Principal, and you can fire requests at a specific endpoint that are only accessible by your resource to get the access_token. But be wary that Azure MSI are still under public preview, so please review the known issues before using it.
The picture above explain how Azure Resource Manager assign a Service Principal identity to your VM.
When you enable MSI in a VM, Azure will create a service principal in your AAD.
Azure will then deploy a new MSI VM extension to your VM. This provides an endpoint at http://localhost:50432/oauth2/token to be used to get the access_token for the service principal.
You can then use the access_token to access the resources such as Key Vault which authorize the service principal access.
Can someone please help me with the query shown below?
I am running DSS server in my development server. I want to connect it to my local machine's SQL Server 2014 with servername using windows authentication. I wasn't able to find any documents related to this.
I added jtds jar in the repository/components/lib folder but still getting below error
In the Dss I configured with below details but getting below error(PFA screenshot)
Error:
Driver class com.microsoft.sqlserver.jdbc.SQLServerDriver can not be loaded
Can you please help me, how to define the connection parameters in the DSS to connect my local SQL Server with Windows authentication ?
Thanks
Mahaboob
Bit of a convoluted answer so here goes.
You can use Windows Authentication with DSS, there are many articles describing how to do this. Just google it. However, the limitation is that you must run the DSS service to impersonate a domain user, then, set the username in the connection string and, magic, the user will be impersonated and you will be connected.
Its not all good news. You will be limited to impersonating one user per DSS instance. So unless you can have a single user configured for all the SQL DB's you will use... you get the point.
The simplest way is to enable SQL Authentication. If you are in a corporate MS type shop, then your DBA'a may advise this is not a good practice. In my case, we were successful in granting special business exceptions to enable SQL Auth.
I hope this is helpful
I found the issue. It is due to sqlserver jar file is missing.
we have to place sqljdbc.jar file into repository\components\lib location to get rid of driver class error. please download the jar file from https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11774
But my question still remains that how to establish a connectivity to a sqlserver using windows authentication?
I have wso2 Identity server in my TEST environment. Team has been using it for some months and lot of users and roles are created.
Recently we have got CA certificates and installed it.
After that we cant add users saying the problem Error while encrypting the Credential for User Name.
Looks like new certificate is the problem.
What is the work around to get around this problem without rebuilding environment?Data is not of much importance.Can clear all the users and roles.
What are the best approaches to over come this?
We are extending an existing software product, which uses Active Directory to store user credentials to a cloud solution to store user credentials.
I am wondering how we can migrate/port these AD passwords to new database instead of asking users to reset their passwords. I know we cannot retrieve the plain password but rather I would like to understand how we can port these passwords and use a specific decryption library to validate these passwords.
We can just move this passwords to new SQL database but how are we going to validate the password? Which encryption algorithm and salt we are going to use?
Thank you,
I’ve spent most of this month working with a customer who is consolidating various Active Directory forests into a single domain. We didn’t use any third party tools – just the standard Microsoft utilities, i.e. Active Directory Migration Tool (ADMT) v3 and Exchange Migration Wizard (one of the Exchange Server 2003 deployment tools) – but they seem to do the job.
As migrating several hundred users to new accounts (with new passwords) would cause a huge number of support calls, I wanted to get the ADMT password migration DLL working. This took some time, but with the help of my enterprise support colleagues (effectively a PSS call), we found a way through. This is what was required:
(For reference, both the source and target domains were in Windows Server 2003 domain and forest functional mode, running Windows Server 2003 with a mixture of service packs 1 and 2.)
Make sure that there is a trust in place between the source and target domains.
Install ADMT by running admtsetup.exe and follow the installation wizard on the computer that will be used for the migration (I used a domain controller in the source domain but ideally you would have dedicated computers for migration activities and it seems logical that this should be in the target domain).
If not already created by ADMT, create a new domain local group called domainname$$$. This group must be empty, and is required in order to migrate the sIDHistory information between source and target accounts.
On the domain controller that will be used to export the account information (usually the DC holding the PDC Emulator operations master role for the source domain), create/set a value of 1 for a DWORD registry key called TcpipClientSupport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\.
In both the source and target domains, ensure that success and failure auditing is enabled for account management.
On a computer with ADMT installed, create a password encryption key for each source domain, by shelling out to a command prompt and entering the following commands:
cd %systemroot%\ADMT
admt key /option:create /sourcedomain:<em>domainname</em> /keyfile:<em>filename</em>.pes
(the domainname can be specified in NetBIOS or DNS format.)
On the domain controller in the source domain that holds the PDC Emulator operations master role, connect to the computer with ADMT installed (e.g. via the c$ administration share) and access the %systemroot%\ADMT\PES folder.
Run pwdmig.exe to install the ADMT Password Migration DLL and follow the installation wizard. During the installation, supply the password encryption (.PES) file that was created earlier.
This is the step that’s not in the instructions – even though the password encyption file was supplied during the installation of the ADMT Password Migration DLL, it still needs to be imported manually on the PDC Emulator, by shelling out to a command prompt and entering the following commands:
cd %systemroot%\ADMT
admt key /option:import /sourcedomain:<em>domainname</em> /keyfile:<em>filename</em>.pes
On the domain controller that will be used to export the account information, create/set a value of 1 for a DWORD registry key called AllowPasswordExport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\. Note that this key constitutes a security risk and should only be enabled during the period of migration.
Restart the computer with the ADMT Password Migrator DLL installed.
Start the Password Export Server service.
Most of this is exactly as per the documentation – the main difference is the need to manually import the password encryption file. Without this, I was receiving the following message:
Error
Unable to establish a session with the password export server. The source password export server and the target server do not have the same encryption key for the source domain.
Finally, what permissions are required? I used Local System for the Password Export Server service. For everything else, I used an account which had been created in both forests with identical passwords and which was a member of the Domain Admins group. That’s a little excessive, and best practice would involve using an account with the minimum required permissions. Basically, an account is required that is:
Domain administrator in the source domain.
Local administrator on the computer on which ADMT is installed.
Delegated permissions on OUs that are targets for resource migration in the target domain, including the extended right to Migrate SID History (visible in the Security for an object using the Advanced Features view in Active Directory Users and Computers).
Further advice can be found in the ADMT v3 Migration Guide.
One option would be to implement a password filter for AD. This would allow you to capture the password as passwords get changed. I have used several products that implement a password filter to assist a ad migration, howevere I have not implemented it myself so the best I can do is suggest the Microsoft doc on it. This isn't a great option if users are not forced to change their password or cannot change this password.
https://learn.microsoft.com/en-us/windows/win32/secmgmt/password-filter-programming-considerations
Another option would be to setup a product in-between the product login and AD to capture and migrate password. Products do exist that implement a ldap interface for exactly this purpose. The product I have seen for this is Radiant logic but I believe there are other products.
https://www.radiantlogic.com/solutions/overview/how-radiantone-works/
I recently had to change my active directory account password.
Ever since then I am unable to deploy BizTalk projects or put my Receive Locations in the stop state (Sendports & orchestrations is fine).
I noticed that my Enterprise Single Sign-On Service isn't running, if I try to start the service it complains about a login failure.
The thing is, you would think that it used my account to start this service and that it can't login anymore because of some old password or something. However I run the service with another user, namely: BiztalkUser. This user is set on the service and u can also see him in the biztalk server configuration.
Anyone have any ideas what I have to do? Cuz I can't do much anymore now.
The procedures for changing service accounts and password is clearly documented by Microsoft http://msdn.microsoft.com/en-us/library/aa561505(BTS.10).aspx please follow the steps outlined under "Enterprise Single Sign-On Service on Master Secret Server" to correct your issue.
I agreed with the first paragraph of answer 1. That would be the first option I would look to correct the problem. The second option would be, restoring the master secret server.
See below;
Open a command prompt - Navigate to C:\Program Files\Common Files\Enterprise Single Sign-On\
Type in command - ssoconfig -restoresecret SSOXXXX.bak
(Where XXXX is a randomly generated name created with SSO was installed. This is the SSO back-up file)
Enter the password - (Again you entered/created/accepted this when configuring SSO in the BizTalk configuration.)
Additionally you should create a new backup file if you have changed the account the SSO service runs under.
To create a new back-up file - ssoconfig -backupsecret latestbackup.dat
If SSO is running under your account and it stopped working when you changed the password, you need to update your password on the service's credentials. You can do this in the serivces control panel. If you have other BizTalk items running under your account, you will need to update them as well... host instances, application pools, etc.
BizTalk User may not not have the necessary permission to run SSO. I'd suggest put the account back in that worked. Comb the error log for other messages to help you diagnose th eproblem. For furtherhelp, I'd suggest posting more specific details of your current problem here (ie. Error Messages, Log Files, etc.).