Credential Discovery Using Windows Proxy Accounts

[Sebastiano Alighieri]

Hello, 

I'm working on a project in which the client needs to manage thousands (25K to be exact) Windows Domain Service Accounts.

These service accounts are like any other AD domain account, except that they have been configured as the "Run As" account on some services and/or scheduled tasks on windows member servers... 17K member servers to be exact.

The client needs to be able to manage those accounts in pam and automate the password rotation across all windows member servers on which those accounts are configured to run as a service.

According to the 3.2.4 documentation Windows Proxy is one of the "subset of out-of-the-box target applications offers the Account Discovery feature." 

see attachment for screenshots of setup

• I've set up the windows proxy device (which is also the target device on which the service is running as the 'svc acct')
• I've Created the Windows Proxy Application, on that Proxy device, set the account type to Active Directory [Lookup DC against DNS], provided the domain name and selected the proxy device as the proxy to use;
• I on-boarded the domain Account linked to the Windows Proxy application and synchronized / verified the account... i also force-changed the password a couple of times.

The issue i'm having is when setting up the discovery profile using the Windows Proxy Account / Server just configured. The option / server is not listed in the available servers list.

I've also switched the Windows Proxy Application Account type from Domain to Local and Back, but still not seeing the server in the discovery profile creation dialogue.

What am i missing?

Thanks in advance.

------------------------------
Services Architect
HCL Technologies Ltd
------------------------------

Attachment(s)

Proxy Application.docx   212 KB 1 version

[Sebastiano Alighieri]

Here's the proxy log

------------------------------
Services Architect
HCL Technologies Ltd
------------------------------

Attachment(s)

cspm_client_log.zip   6 KB 1 version

[Ralf Prigl]

​Hi Sebastiano, One known problem is discussed here: https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=122702&_ga=2.77372060.867334655.1563556191-1213293715.1559659504

Do you have another target application configured for the device that does not support account discovery?

[Sebastiano Alighieri]

Hi Ralf,

thanks for the reference.

The client is on 3.2.4. Does that mean that the client would need to upgrade to 3.3 to resolve that issue?

Any chance that the "fix" in 3.3 could be back-ported to 3.2.4 - don't want to send a client on a fools errand if it isn't possible or wouldn't even be considered.

thanks.

------------------------------
Services Architect
HCL Technologies Ltd
------------------------------

[Sebastiano Alighieri]

Re "Do you have another target application configured for the device that does not support account discovery?"

My observations above were in my own test lab, and yes, I do have other applications linked to the same device which are NOT enabled for / do not support credential discovery.

I haven't checked on the client's platform, but i'm almost certain they will run into a similar issue since they say they have roughly 17k devices in PAM.

------------------------------
Services Architect
HCL Technologies Ltd
------------------------------

[Ralf Prigl]

It is rather uncommon to have multiple target applications with different types associated with the same device, as the application type reflects the device type. I would say this is more likely to be found in a test environment with a few devices than in a production environment with thousands of devices. There are no plans to port the fix back to 3.2.4. PAM fix strategy is discussed in https://casupport.broadcom.com/phpdocs/7/9526/9526-PAM-fix-strategy.pdf

[Sebastiano Alighieri]

Thank Ralf for the reply.

And so, is the reason for the fix in 3.3 the fact that windows member servers​ are commonly on-boarded and linked to MSSQL (as unix hosts to Oracle) Applications before the client realizes they need credential discovery functionality?

or is there a more pragmatic reason for it?






------------------------------
Services Architect
HCL Technologies Ltd
------------------------------

[Ralf Prigl]

Hi Sebastiano, ​I can't say I understand your question. If the question is why the fix is in 3.3, but not in 3.2, the answer is that it was fixed recently and that there was no demand for a hotfix prior to the 3.3 release. Now that we have the solution published as part of the new release, there will not be a hotfix for it per our fix strategy, unless this is critical for a customer who cannot upgrade to 3.3 at this time.

[Sebastiano Alighieri]

Hi Ralf, 

thanks for the response and sorry for the confusion. 

I'm asking why was a fix produced in 3.3 for an uncommon issue; obviously there must have been a demand for it, but i'm wondering what were the use-cases?

Did clients first on-board devices and link them to MSSQL applications or Oracle Applications before they attempted to create a 'Proxy' or 'Remote' or 'Unix' applications linked to the same device for credential discovery purposes?

or... was there some other driving factor behind the fix?

Thanks again.

------------------------------
Services Architect
HCL Technologies Ltd
------------------------------

[Ralf Prigl]

The problem was observed during testing, and it was fixed in current code once the root cause was identified. Nothing unusual about it. I believe it was a Generic application type that had been defined for a UNIX device just to store some passwords that were not meant to be kept in sync, and that caused the problem of an account defined for a UNIX target application tied to the same device not being available for discovery.

[Sebastiano Alighieri]

ok, thank you.

------------------------------
Services Architect
HCL Technologies Ltd
------------------------------