Your customer is moving an existing corporate application to Google Cloud Platform from an on-premises data center. The business owners require minimal user disruption. There are strict security team requirements for storing passwords.
What authentication strategy should they use?
Federate authentication via SAML 2.0 to the existing Identity Provider is the best strategy. This approach allows users to continue using their existing corporate credentials without needing to synchronize their passwords to Google Cloud Platform, thereby adhering to strict security requirements for password storage. Federation minimizes user disruption as users can access the application using their familiar login credentials. Additionally, it leverages the secure authentication mechanisms of the existing Identity Provider.
The correct answer is B. GCDS tool only copies the usernames, not the passwords. And more over strict security requirements for the passwords. Not allowed to copy them onto Google, I think. Federation technique help resolve this issue. Please correct me if I am wrong.
GCDS synchronises password as well and that is the reason why B is the correct answer. Only in B the password doesn't get copied to GCP.
Passwords are also synchronized: https://support.google.com/a/answer/6120130?hl=en&ref_topic=2679497
C is the answer
B is the answer. Why ? GCDS syncs passwords - Ok but which passwords? Clients need to provide a new password for accessing Google Cloud after GCDS sync. Google recognizes the user because GCDS populated the user list. The user is redirected to a standard Google sign-in screen where they enter their standard username and Google Cloud-specific password. The issue here is the two sets of passwords. Even if a user manually sets them both to the same value, they aren’t managed in a single place. If you need to update your password, you’d have to do that in AD and then again in Google Cloud Identity. In some cases, this approach can allow for better separation between your on-premises environment and Google Cloud, but it’s also one more password to manage for your users.
This should be the top comment. It explains in detail the proccess
"A" will syncronise passwords between on pre-mise and the GCP, this duplicates the existing strategy plus Google's "built-in" encryption of all the data. "B" does not support the moving to GCP. "C" The directory sync tool copies the filesystem settings between servers, UNIX filesystems have permission settings built in and passwords to log into the permission groups, syncing these would set GCP up the same way their on-premises is, plus Google's "built-in" encryption. "D" disrupts the users, so this is not correct. The debate should be between "A" and "C", "C" includes "A" according to (https://cloud.google.com/solutions/migrating-consumer-accounts-to-cloud-identity-or-g-suite-best-practices-federation) so choose "C"
GCDS syncs user accounts and some other LDAP attributes but not the passwords, with hybrid connectivity to GCP, SAML (or federation) is the preferred method. Answer should be "B" https://cloud.google.com/solutions/patterns-for-authenticating-corporate-users-in-a-hybrid-environment https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-synchronizing-user-accounts#deciding_what_to_provision
GCDS does sync passwords. Please refer - https://support.google.com/a/answer/6120130. Since the question says client wants to move to GCP , C should be the answer.
This is the best answer so far.
The article implies that ADFS is best but suggests you also need the GCDS. This makes sense, you need the users in Google to allocate permissions but you don't want to copy the passwords across hence ADFS.
B is supported read https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-configuring-single-sign-on
There is no mention SSO is needed.
B is ok.
miss typed.. C is ok
B, you dont want to store password as per security guidelines provided in question.
B. Federate authentication via SAML 2.0 to the existing Identity Provider - Federated authentication allows users to sign in to the Google Cloud Platform using the same credentials they use for their corporate accounts. It delegates the authentication process to an existing Identity Provider (IdP) that the company uses on-premises. This approach minimizes user disruption, as users don't have to remember a separate set of credentials for Google Cloud, and it allows the company to maintain its existing security policies and password storage requirements.
B. Federate authentication via SAML 2.0 to the existing Identity Provider. Here's why: Security: SAML 2.0 allows for secure single sign-on (SSO) without storing passwords on Google's side. It ensures that authentication happens against the corporate Identity Provider (IdP), which maintains control over the user credentials. Minimal Disruption: Users can continue to use their existing corporate credentials to access the application on GCP without having to remember a new set of credentials or go through a password change process. Compliance: It satisfies the security team's requirements for password storage by ensuring that passwords remain within the corporate boundary. Integration: SAML is widely supported and can be integrated with many IdPs, allowing for a seamless transition to cloud-based resources while leveraging existing identity management infrastructure.
Federation would connect to existing Identity Provider that runs who knows where. Using GCDS corporate accounts will create application user identities in GCP and will let you use those identities in the Cloud (as the question objective implies)
I think it's B because they want minimal user disruption, and only this option focuses on using the same password. Plus, they want to move ONE existing corporate application, not all their infrastructure. A. I don't think this meets a strict security requirement, and if they eventually need to change the password, I think this would not be synced or may have issues syncing both passwords. C. We don't want to provision new users; we want to keep users with minimal disruption and doing what they do already taking the least steps possible. D. Probably a terrible security practice; if anything, we would like them to use one password and sign in from there. B seems to me the most fitting.
Federating authentication aligns with strict security team requirements for password storage, as it avoids the need to store or sync passwords outside the corporate environment.
The correct answer is C. Google Cloud Directory Sync will provide federated authentications. B is wrong because SAML is used for Single sign-on. It also doesn't mention how the cloud can be authenticated to the existing Identity Provider. SAML by itself is not enough to do the job.
I don`know what GCDS has to do with passwords, it has to be B
It is C. You move to gcp so copy and use from gcp now.
The question is ambiguous, though C is the righter answer :-) https://cloud.google.com/architecture/identity/reference-architectures GCP uses GCDS to sync On-prem Azure Directory/LDAP user/groups. It assumes that all on-prem IdP are active directory, which might not be the case.
B is the correct answer
main reason for B are strict storage requirements.
GCDS is better as it is a corporate application. The requirements for storing password can be met by GCP. As GCP has many security features For SAML, the corporate needs to have Identity provider service such as the one provided by Google, Facebook
Also the application needs to be modified to use identity provider service, if they are going by choice B
B is a preferred solution nowadays, that's why: https://cloud.google.com/architecture/framework/security/identity-access#use_a_single_identity_provider
Minimal User Disruption: Users continue using their existing corporate credentials for both on-premises and GCP applications, avoiding password resets or new account creations. Security Team Requirements: GCP doesn't store or manage corporate passwords; authentication relies on the existing Identity Provider (IdP), meeting strict password storage requirements.
the most convenient way is B, but the principle of this kind of exam is use cloud provider's native tools, so the C is correct.. this principle is also used on aws