I am in the middle of an Active Directory Migration and need to keep user passwords synchronized between the old and new environment.
As I want to implement a Service for getting the Job done and don't want to use the API of ADMT (Active Directory Migration Tool) I am in the need of a method to copy Passwords from the old account to the migrated one.
Does anybody know about a Windows API function that is capable of copying passwords from an account across Domains to another one - which is the migrated version of it?
Related
we have an on premises Active Directory. The environment got hacked and domain controllers were restored to a backup that is clean according to forensic people.
For better explanation, let's assume the hack occurred on October 1st and the backup it got restored to was from September 1st.
All local accounts that were created and synchronized before September 1st are fine. All local accounts that were created and synchronized between September 1st and October 1st are lost on premises.
A new AADC instance has been installed, configured and is synchronizing happily. For some reason, the accounts created after September 1st and before October 1st were not deleted in the cloud when AADC started synchronizing again. We do not know why. They do not exist on premises any more though.
These local accounts are supposed to be created again, so they can access on premises resources.
I looked at Microsoft documentation about soft/hard matching in AADC: Azure AD Connect: When you already have Azure AD | Microsoft Docs
It states that object newly imported to AADC will be hard matched or soft matched if possible and afterwards, AAD will mark them as " Directory synced". It also states:
The match is only evaluated for new objects coming from Connect. If you change an existing object so it is matching any of these attributes, then you see an error instead.
My question is: If we have those accounts in the cloud that are marked as "Directory synced" and create them on premises, will this be considered as a "new object" by AADC and hard matched or soft matched? Or will this cause duplicate accounts in the cloud or the error mentioned above?
If we stop the AADC sync service locally, create the accounts on premises and assign those newly created on premises accounts the same "sourceAnchor/immutableID" value as the cloud object and restart synchronization, will this work or will it cause an error?
Thanks!!!
• First, reverse synchronization, i.e., synchronization of user identities from Azure AD to on premises AD is not possible as of today even using Azure AD Connect. There are only few attributes that can be written back, and that's mostly for hybrid configurations, and passwords if you have the corresponding feature (and licenses) enabled. So, in your case, if you have enabled ‘password writeback’ and ‘password hash synchronization’ in Azure AD Connect, then only you can edit these properties of the users in on premises through Azure AD. Also, if that’s what you want, you can simply export the list of users via PowerShell (Get-MsolUser/Get-AzureADUser) or the Graph API, along with any relevant attributes, then use the exported data to recreate them in AD (again, PowerShell helps). You cannot export passwords. Once the export/import is done, you can "match" the on-premises users with the cloud ones and give them the SSO experience. The process is known as soft match. The other type of syncing between both the environments is called hard match. You can find more details in the link below: -
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-existing-tenant#sync-with-existing-users-in-azure-ad
• But there is a way you can try as given in the links below by creating those users who were created during that month whose backup isn’t available and ensuring their domain suffix and email as well as alias attributes are identical to those as synced in Azure AD during that month. Thus, when you create users identical, primary SMTP, email, alias, and domain suffix, you may be able to sync these users’ identity once again to the same identities synced(created) in Azure AD earlier. Please refer the links below for detailed steps to follow: -
https://support.microsoft.com/en-us/topic/how-to-use-smtp-matching-to-match-on-premises-user-accounts-to-office-365-user-accounts-for-directory-synchronization-75673b94-e1b8-8a9e-c413-ee5a2a1a6a78
https://www.slashadmin.co.uk/how-to-sync-an-existing-office365-tenant-into-a-new-active-directory-domain/
We are using a third-party IT provider that handles our network administration and domain accounts, but as part of moving to a different office and setting up new infrastructure, we are considering dropping that and using Azure Active Directory only.
Researching the topic online seems to indicate that Azure AD is not a complete replacement for on-premises Active Directory, as things like local resource access and group policies outside of Azure would be missing. However, we are moving towards using Azure for most things (file storage, etc), so that should be fine if we still have that functionality there.
Before finalizing the decision to go in that direction, we just need to be certain of a few things:
1) Is there a way to create a new account in Azure AD so that it can be used to login from any machine in the office, without having to create it locally first and then connect the two?
2) Is there a way to sync user data, such as user/desktop files, across any devices the account is used to log into?
3) Is it possible to have an office printer configured in Azure so that it can be used with an Azure AD login, completely independent on any on-premises setup (i.e, not Hybrid Cloud Print, which seems to require an on-premises network/AD to be joined with Azure AD)?
The goal is to be able to log in and work from any internet-connected device, whether in the office or at home, without needing to use a VPN and/or remote desktop, and forego on-premises AD administration.
This is possible as long as the device is joined to Azure AD. Once the device is joined to Azure AD, then newly created cloud-only users can also login to the devices.
Ref: https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-azure-ad-join
Enterprise state roaming should help in this aspect. It might not cover everything you are looking for but the important app-specific data and user settings are synced.
Ref: https://learn.microsoft.com/en-us/azure/active-directory/devices/enterprise-state-roaming-overview
There is no direct solution from Microsoft for pure cloud scenarios. There are few 3rd party services offered for this.
Ref: https://appsource.microsoft.com/en-us/product/azure/printix.64182edf-4951-40d5-91c8-733e1c896b70
Hope this helps.
I have been trying to access liferay using my Active Directory account but i am not able to sign in, knowing that the users are imported successfully but it seems that liferay doesn't import the passwords. How can I solve this issue?
AD Environment: Windows Server 2012
Liferay 6.2
With LDAP you typically don't want to distribute your passwords all over - password management is on one side, e.g. on LDAP, and the password policy that applies there should carry on everywhere. When you change your password on LDAP, would you want to be able to log in to your portal with the old password? One positive aspect on having passwords in a separate system (like LDAP) is that they can't get loose should there be any security issue in your front end application (like Liferay, but by far not limited to it).
In fact, I prefer to add an SSO system, so that Liferay never even sees any password. Further, passwords are hopefully stored in a salted&hashed way, so that you can't "just get" them out of any system. Granted, during login without SSO, Liferay knows the password, but I'm actually happy when that's not written to the local database.
If you rely on your Liferay database to have your correct passwords, you should be changing your architecture. To me your description sounds like "yay, works as expected".
We have an application that accesses Hadoop via HDFS, YARN, and Hive interfaces. This application works fine against Kerberos-secured clusters if kinit has been run. It also works fine if we call UserGroupInformation.loginUserFromKeytab(). We are able to delegate the HDFS and Hive tokens to YARN applications. The thing we cannot figure out is the following scenario:
The Hadoop cluster is secured using Kerberos
The Hadoop cluster either uses Active Directory as its KDC, or has
established a one-way trust between its KDC and the AD controller.
Our software is running in a session that has been authenticated
using AD directly on Windows, or via PAM or LDAP (or some other mechanism) on
Linux.
Our software queries the active AD session to extract a TGT or
equivalent, and relays that information to the Hadoop APIs (via
UserGroupInformation, presumably).
Hadoop authentication is thus achieved without the need for the user
to enter a principal, password, or keytab.
We know this is possible in theory, because there are two examples of software that achieve this. The first is HDFS Explorer from RedGate. The second is Hue. However, we just can't seem to figure out the right incantation, and even Hortonworks support can't seem to help.
Hue comes with a LDAP backend that can transparently authenticate users against your company directory,
Hue also comes with a KT renewer command for keeping its Kerberos ticket up to date. It is even ran automatically when using CM.
I want to create a publication task in Jenkins to automatically publish my database changes along with my application.
If I understood correctly, a common practice is to create a publish profile that includes the database name as well as the account (login and password) of the account used for the deployment.
This means that the deployment account username and password will be stored in clear text on each developer computer as well as on the version control server and the continuous integration server.
Even though I created a specific login and password for the deployment, it seems pretty unsecured to me.
Is there a workaround? I can only think of replacing the password within the msbuild command line on the continuous integration server.
tl;dr version
Windows Authentication is the preferred, secure method of connecting to your SQL Server instance and if it's possible to use that then it's recommended to use that for connections.
If SQL Authentication is used then the default in publish profiles is that the password isn't saved. For build servers and other shared profile scenarios you may need to accept lower levels of security (by editing the publish profile to add the password, or setting it as a parameter in the build configuration) or work around it in some other way (custom script that reads it from some kind of a secret store, such as an encrypted value).
Long version
Windows Authentication: If at all possible use Windows Authentication, giving permissions as required to users who need it. For Continuous Integration scenarios you would need to give appropriate permissions to the account the build server executes under - full details are in the recent whitepaper on the SSDT blog.
SQL Authentication: If you look at the publish profile (Open With... Xml Editor) you'll see that the password information isn't actually stored there.
If you choose "Save Password" you'll have "Persist Security Info=True;" stored in the connection string rather than the password itself.
When a connection is made to a server/database in SSDT with "Save Password" enabled, the connection info is encrypted and stored in the registry under "HKEY_CURRENT_USER\Software\Microsoft\SSDT\ConnectionStrings". This has to be present on the machine in order to successfully publish using the publish profile.
Hence in a team environment every user would need to connect at least once before that publish profile would work for them. However, the password would be safely encrypted on user machines.
For the build server, your options are more limited. One possibility is to manually log in as the build server user and then connect to the database, but this isn't very scalable. To avoid the less secure options you mentioned you'd need to implement your own logic for persisting the password securely. You can look at the Protected Data API which can be used to do something similar to what SSDT does but on a per-machine level, or use an encrypted configuration file.
If you have to use SQL Authentication I think passing the password into the publish action as part of the build configuration may be the "best" way to go in terms of a tradeoff between ease of development and security. At least that way you can restrict who can view and edit the build configuration in TFS and regular developers won't see it.