Hello, everyone. I have a few questions about how you do things or what the best practices are.
1.Non-domain servers.
I have about 50 non-domain Windows servers—do I really need to create a separate service account for each server?
Could I instead have one account with the same password on different servers? What should be entered in the “Domain” field? If I leave it blank, PAM won’t connect to the target server; if I specify the target server’s name or “.”, it works.
If I add a non-domain server to the resources using its IP address, is there any way to change that server’s name to a DNS name or the server’s hostname so that a friendly name appears in the resources?
I’ve also noticed that it’s not possible to create the same user with different passwords as Service account.
We have a case where we need to grant access to a server with a specific local user, e.g. “SpecialUser.” Is it possible to configure it so that only one session is allowed—i.e., if there’s already an active session, no one else can log in?
2. SQL Server
Does anyone have instructions or can briefly describe the best way to configure a PAM connection to a single SQL Server database? Is it possible to restrict the user’s actions so they cannot perform other operations on the server?
For non Domain server , you can create the same username and password on each server , and used it for your 50 servers.
Just put it in Service account first :
Yes this is what we doing now, but in case i need to change password for one server service account, i cannot create same account on PAM with different password..
I have about 50 non-domain Windows servers—do I really need to create a separate service account for each server?
Personally, I would advise creating separate accounts for each machine. You can leverage the API to add the credentials since 50 is well above what I would want to do manually. I haven’t done so myself, but just checked and it looks like these service accounts credentials are leveraging the credential API endpoint and would be easy enough to bulk add.
Using a single service account across all 50 servers could result in a single endpoint credential compromise extending to all non-domain joined servers.
If I add a non-domain server to the resources using its IP address, is there any way to change that server’s name to a DNS name or the server’s hostname so that a friendly name appears in the resources?
I believe this is a bug/issue with the Netwrix platform. I’ve raised an issue to support ~6 months ago regarding certain text fields not properly updating in the UI when updated at the resource level. The resource screen should correctly show the new DNS name, but you might have the same issue with seeing the updated name from the resources pane.
I’ve also noticed that it’s not possible to create the same user with different passwords as Service account.
This is a huge pain from Netwrix and seems to be a completely pointless requirement for the platform. You can get around it by adding the domain field to be the name of the server. IE: server hostname is TEST01. The domain field should be set to TEST01. This will allow reusing the same username since it’s under a different domain and the service account should still function properly. This is how we workaround the issue for our off domain Windows servers.
We have a case where we need to grant access to a server with a specific local user, e.g. “SpecialUser.” Is it possible to configure it so that only one session is allowed—i.e., if there’s already an active session, no one else can log in?
You can totally do this using a custom Powershell activity step. You would have to query the current sessions on the host and if there is a session for your specific user, raise an error and halt the activity. If you need some help with that, let me know and I’ll be happy to offer whatever information I can.
Does anyone have instructions or can briefly describe the best way to configure a PAM connection to a single SQL Server database? Is it possible to restrict the user’s actions so they cannot perform other operations on the server?
Assuming there are no network policies restricting endpoint machines from hitting the DB, you can create an activity that adds the user (managed or not) to the database role you configured. Then assign this activity with a connection profile that releases the credential to the user (if using managed accounts) so that they user can use a DB client from their machine to connect to the DB. Then you have no need for the RDP session.
If RDP to the server is required for recording purposes, simply add the user to the remote desktop user role as well as using the database role assignment activity step.
Hope this take on how another team would handle these issues helps. I haven't been able to find any best practices specifically from Netwrix, so we have just been experimenting with what works best for our workflows so far.
Thank you for such an answer—you’ve just confirmed what I was thinking.
Another point: if we add a non-domain server to the resources using its IP address, that IP will be shown as the server name, if we use its DNS name or hostname, then that will appear as the resource name.
The problem with SQL is that we use the RAG Portal and an RDP session is always required. My initial thought was whether it might be possible to embed only the SQL Studio application into the RAG Portal, but based on what you wrote, I think a separate workstation with just SQL Studio will be necessary.
I’d also be grateful if you have and could share a PowerShell script for managing the same user’s session, in the meantime, when I have time I’ll try to look into it myself.
Ahhh, we don’t use the RAG Portal so I can’t give much help regarding potential workflows through that. Best of luck working on that process though!
Regarding the PowerShell script for checking logged on sessions for a specific user and ending the activity if a session is found, I can get something put together at some point this week. Let me see what my schedule looks like and if I have some time I will get it into the show-and-tell area and pass it along to you.
