Active Directory password porting/migrations to database - encryption

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/

Related

Best practices for connecting from ASP.NET Core to SQL Server?

I've had some recent difficulty with SQL Server not liking the default AppIdentityUser for logins, so I went ahead and created a custom DB user with write access.
But it made me wonder - is this the best approach?
I was wondering what the best SQL Server login approach would be for Asp.Net Core. I know there's a question similar to this for normal .NET, but you can't encrypt a Core web.config/appsettings.json (well, in a quick and straightforward manner).
Here are the options as I see them:
Connect via SQL Server ID that is stored in appsettings.json.
Pro: Already configured.
Cons: Password in web.config/appsettings.json; have to specifically configure SQL Server ID. Not centrally revokable.
Connect via user NT ID via ASP.NET "AppIdentityUser".
Pro: No passwords in appsettings.json.
Cons: Not centrally revocable. Seems to be restricted to the server name for user.
Connect via Active Directory user.
Pro: Easily revokable.
Cons: Active directory user password in appsettings.json. Could be bad if somebody accidentally reuses that user in another application in the company, and that user gets breached.
Are there other options that I'm missing? Which of these options are used in which situations? Which are more standard? Are there pros and cons that I'm not thinking about?
You should absolutely use a custom SQL Login to connect to the database. Under the hood, the SQL Login could be tied to a local account, service account, network account, etc. It doesn't actually matter.
The real issue you seem to be having here is in not wanting (rightly) to expose login credentials in plain text. I'm not sure why you keep referring to Web.config here, as ASP.NET Core doesn't use that. Instead, there's various configuration providers that can be optionally utilized. By default, ASP.NET Core (at least since 2.0) adds a JSON config provider that looks for appsettings.json and appsettings.{environment}.json in your project, a command-line configuration provider, a user secrets config provider, and finally an environment variable configuration provider.
The last two are the most interesting for your circumstances. In development, you should use user secrets. In production, you should use environment variables. However, neither stores secrets in an encrypted way. The benefit to either approach is that the secrets are not in your project, and therefore also not in your source control. Even though neither is encrypted, it's not as big of a concern as you might think. Getting at the secrets in either would require direct access to the server/development machine. Additionally, user secrets is by default tied to a particular user account, accessible only to that user, and environment variables can be set up the same way. Therefore, someone would need to both gain access to the machine and gain access to the particular account. That's actually a pretty high bar, and if it were to occur, exposing a database password is really the least of your concerns at that point.
Nevertheless, if you want true encryption, you have the option of using Azure KeyVault. KeyVault can be used whether or not your application is actually hosted in Azure, and while it's not free, it's exceedingly cheap.
Finally, you can always create your own config providers or source third-party ones. For example, while the default JSON provider doesn't support encryption, you could potentially write one that does.

Having a Linux server with key pair and ssh private key. Ppk in Windows desktop application for server login

I have a Windows desktop application from where I need to login Linux server for accessing a configuration file from server. Hardcoding the Linux username and password in my code will not be a gud idea. So having a private key in my local and adding the same key to Linux server authorised keys and providing read access only to the specific config File for one user. (no access to other files in Linux server for that particular user) would this be a right idea with respect security purposes??.. Or any idea how to login Linux server from windows application securely.
scp is built to do this already as part of ssh.
Winscp is a well known free scp client for windows that already has features to script and automate transfers.
See https://winscp.net/eng/docs/guide_automation
So yes, create a user that has access to the config file.
Create a key pair and add the pub key to an .ssh directory you create in the user's home directory. Perms for the directory and file need to be owner only.
As you mentioned pub key needs to be renamed to authorized_keys.
Make sure you convert the key appropriately for the os.
Openssh and putty keys are in different formats but there are tools for each that will let you convert one format to another.
On your windows machine you need the private key, not the public.
You can track your login security constantly with Data Leak Detection tools. I use Hivecode for this purpose. It helps to know for sure if anybody else has access to your server and to your digital assets. I was already notified once and I've got all the information about the theft of my source code.

Where does one place the Always Encrypted Certificate on an IIS 7.5 web server?

We have a SQL Server 2016 database that employs Always Encrypted. Our recently published ASP.net web site attempts to pull data from this database, and when it does we get this error:
Error: Failed to decrypt column 'EnSSd'. Failed to decrypt a column encryption key using key store provider: 'MSSQL_CERTIFICATE_STORE'. The last 10 bytes of the encrypted column encryption key are: 'B8-48-B3-62-90-0B-1D-A6-7D-80'. Certificate with thumbprint '97B0D3A64CADBE86FE23559AEE2783317655FD0F' not found in certificate store 'My' in certificate location 'CurrentUser'. Verify the certificate path in the column master key definition in the database is correct, and the certificate has been imported correctly into the certificate location/store. Parameter name: masterKeyPath
Now we know that this means that the certificate has not been placed in the proper location on the server. During development we simply placed the certificate in the Certificates snap-in under the Personal Certificate Store, and that worked, however now that the site has been published we tried doing the same on the web server but it's not working (we kind of figured it wouldn't).
Anonymous Authentication is enabled on the site and the anonymous user identity is IUSR. ASP.NET impersonation is disabled.
Where is the proper place to put the certificate?
UPDATE - we got it to work by changing the Application Pool Identity account to the one that created the Certificate. It was also the account used when adding the certificate to the Current User-Personal list on the web server. We would rather not use this account, so again, where is the proper place to put the certificate?
Always Encrypted requires that the user that is accessing the database to have both the public and private key, which is what it appears to require you to use the account to generate the certificate as they will have this key.
What I usually do is generate the certificate and export the cert with a private key and secure passphrase. Then import the cert with key into the personal store of the account you use to run the app pool. This cannot be a generic integrated account and must be a service account you specify.
run a powershell script as the user:
whoami
COMPUTER\myIISPoolUser
Set-Location -Path cert:\localMachine\my
Import-PfxCertificate –FilePath c:\AlwaysEncrypt.pfx
or use mmc.
whoami
COMPUTER\myIISPoolUser
certmgr.msc
You must also allow the APP Pool user load user profile
IIS can't recognize the certificate from local user, while creating the certificate in SQL server, by default it's putting in to the local user store, do the following things and make sure the certificate generated under local machine -> current user certificate store
Generate the encrypted columns with default certificates
Undo all encrypted columns in to plain text
Go to the certificate and key from the table security "Your DB - > Tables - > Security -> Always Encrypted Keys" and right click the "CEK_Auto 1" -> Script Column Encryption Key as -> Create to new window, keep this generated script
Delete the CEK_Auto 1
Do the step 3 for "CMK_Auto 1" certificate and delete this as well
in the "CMK_Auto 1" script change the certificate path "CurrentUser" in to "LocalMachine"
you example path will be like this "N'LocalMachine/my/G4452V8ERH035D2557N235B29MWR0SV834263G26'"
execute the CMK_Auto 1 and CEK_Auto 1 script
make sure the certificate generated local machine personal directory
it will work, if not test with IIS express that means still your certificate held in local user personal directory
rest all same make sure the "Column Encryption Setting = Enabled" added in the connection string.
Thanks
John Rajesh J
Running on IIS Express is different from running on IIS.
when we create Column Master Key (CMK) from SSMS at that time it generates Always Encrypted Certificate based on which location we have set while creating CEK.
For IIS, you have to generate certificate under MyLocalMachine, and then install certificate on hosting server with administrator rights. this will work for you.
You also need to give access of that certificate to IIS User. This can be done by right click on certificate and then click on manage primary key and add IUSR.
I had the same issue and here's what solved it for me.
Run SSMS as administrator
Right-click the first column you want to encrypt and select Encrypt column...
In the wizard to encrypt the column, under Select a master key source, select Local Machine and not Current User. (In my case, the Local Machine option only appears when I am running SSMS as administrator, hence #1).
Then launch mmc.exe. Under File > Add/Remove Snap in..., add the Certificates snap-in. When prompted, select Computer Account then Local Computer.
Now that Certificates has been added, expand Certificates (Local Computer) > Personal > Certificates, select the Always Encrypted Certificate you just created, right-click it and go to All Tasks > Manage Private Keys..., then make sure the user who is going to access the database has read permissions.
If you want to move the database to another machine, in this same MMC window, right-click the certificate, then All Tasks > Export. When prompted, choose the option to export the private key with the certificate (won't work if you don't). You'll need to enter a password before exporting. Once exported, import it to the other machine using that same MMC window. You'll need to enter the password you created when exporting and again make sure your user has read permission to it.

BizTalk Enterprise Single Sign-On Service problem

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.).

Using Active Directory to authenticate users in a WWW facing website

I'm looking at starting a new web app which needs to be secure (if for no other reason than that we'll need PCI (Payment Card Industry) accreditation at some point).
From previous experience working with PCI (on a domain), the preferred method is to use integrated windows authentication which is then passed all the way through the app to the database using kerberos (so the NT user has permissions in the DB). This allows for better auditing as well as object-level permissions (ie an end user can't read the credit card table).
There are advantages in that even if someone compromises the webserver, they won't be able to glean any/much additional information from the database. Also, the webserver isn't storing any database credentials (beyond perhaps a simple anonymous user with very few permissions for simple website config)
So, now I'm looking at the new web app which will be on the public internet. One suggestion is to have a Active Directory server and create windows accounts on the AD for each user of the site. These users will then be placed into the appropriate NT groups to decide which DB permissions they should have (and which pages they can access).
ASP.Net already provides the AD membership provider and role provider so this should be fairly simple to implement.
There are a number of questions around this - Scalability, reliability, etc... and I was wondering if there is anyone out there with experience of this approach or, even better, some good reasons why to do it / not to do it.
Any input appreciated
Having used ADAM in a project, I found it to be bear. Documentation for developers can be sparse, it has quirks that differentiate it from full AD and, most importantly, I could not get a straight answer from MS as to whether it will be fully supported in the future. The impression I got was that ADAM was the bastard child and that the new Federated services (ADFS) was where they wanted people to go. Just moving the ADAM store from one member server to another was a pain. Now that said, my issues with ADAM had to do with development against and maintenance of the store, It definitely has the ability to scale and it was reliable. That said there are times when you need to delve into 80th level spells of LDAP/Directory magic to figure what it is or is not doing.
For a public facing site, AD/ADAM might be overkill IMO. You could use alternate MembershipProviders like the SqlMembership provider to get the good level of security with respect to credentials. If you wanted to go further, you could use database encryption (SQL Server at least has this ability built-in) to encrypt information that falls into the PII (Personally Identifiable Information) arena and of course encrypt the backups. The advantage that a database backed authentication store has is that you have all the tools that your database product provides to scale out, do backups, control access and so on.
EDIT: Let me add, that with .NET you can setup your site so that it runs under a Windows user and connects to the database using Windows Authentication (assuming the db supports it). Thus, no credentials need to be stored in a config file. However, if you had to store credentials for whatever reason, you can then use DPAPI to encrypt the credentials in the config file.
ADDITION In response the question about securing encryption keys you have a couple of choices. The first is to simply hash the credit card numbers. That greatly simplifies any problems with access to the data however, it means that the customer would have to re-enter their card number for each purchase. If you want to remember the customer's card number, then you move into a new realm of maintenance of the decryption keys. In this scenario, you absolutely should use Windows Authentication to the database and look into SQL Server 2008's Extensible Key Management feature which lets you hook-in a third-party key management program into SQL's encryption functionality. In this way, only the website user would have access to the keys used for decryption. There are other solutions to ensure that the website cannot be compromised. The greater worry is that someone gets a copy of the database undetected. Here's a link on using SQL Server to be PCI compliant:
Deploying SQL Server 2008 Based on Payment Card Industry Data Security Standards (PCI DSS) Version 1.2.
couple ideas
Run AD/AM - Active Directory Application Mode.
It scales well. It's the same core code as AD. Similar management capabilities. Solid reliability. Works with the ASPNET AD Membership Provider.
And it's included in Windows.
Also consider exploring a federated identity system, via ADFS 2.
unlike AD/AM, this approach is fairly leading-edge. The final version of the ADFS v2 server is not yet available from Microsoft, but it is at "release candidate" stage. If you have the stomach to be an early adopter, ADFS2 holds the possibility to employ a federated identity approach. That means you could accept identity tokens from a variety of existing sources: a google sign-in, a yahoo sign-in, any OpenId source, and use that as the identity on your site. Users would not have to "register" and authenticate to you. Instead, your site would honor the identity and authentication provided by some trusted third party, and perform authorization based on that identity.
This is not a direct answer but having a AD user account means you need a windows CAL for that user. Another way would be to issue client certificates to user and map client certs to AD users in IIS.
You might also consider AzMan with SQL store available from Windows 2008 onwards or the open source netsqlazman.

Resources