What is the difference between Agent User ID (Settings tab) and User/Password (Transport tab)? Please share the scenarios of both two when configuring the replicating agents in AEM.
This is well documented in Adobe's documentation here
The context that is missing is to understand the how ACLs work, each user/group has certain privileges/rights; which outside normal CRUD operations include Read ACL, Edit ACL and Replicate. You can read about them here
Now coming to your question, a replication agent has host configuration (the system on which it is setup) and target configuration (the system it connects to). Agent User ID is used for the host system while User/Password on transport tab is for the target system.
For a replication agent on author, the user used in Agent User Id must have read and replicate rights on all path that need to be processed where as user specified in User/Password on transport tab must have create/write access to replicate the content on Publish instance.
Related
Azure network manager security configuration “NRMS-ZeroTrust...” created 54 inbound port rules on my Azure VM which closed my active RDP session and blocked all access to SQL Server.
Is anyone else having a similar issue with their Network Manager (preview)? A screen print of my Azure VM Networking and Vnet Network Manager is below although in preview it looks like stackOverflow has blacked out the rule information you need to see.
I have selected “leave preview” but this didn’t remove the rules.
I see the Remove and update Azure Virtual Network Manager Preview components checklist, but I have no idea what “undeploy the security admin configuration deployment” means as there is no link in the doc. Unlike all the other Azure VM Networking Inbound Port Rules, you can't drill into or delete the rules created by the ZeroTrust config. Creating a rule to explicitly allow the IP of my workstation is ignored.
• You can surely ‘undeploy the security admin configuration deployment’ that has been enabled by accessing the NSG (Network Security Group) of your VM. Also, as you stated that the ‘Zero Trust’ configuration deployed has blocked your access to the VM through RDP and to the SQL Server, it is as such blocked because the similar kind of rules have been configured on the Azure Network Manager with regards to the virtual network in which your VM is configured.
• Also, a security admin rule allows you to enforce security policy criteria that match the conditions set. You can only define security administrative rules for resources within the scope of the Azure Virtual Network Manager instance. These security rules have a higher priority than network security group (NSG) rules and will get evaluated before NSG rules. Also note that security admin rules don't change your NSG rules.
Security admin rules can be used to enforce security rules. For example, an administrator can deny all high-risk ports or protocol from the Internet with security admin rules because these security admin rules will be evaluated prior to all NSG rules as that have been done with you.
• Thus, to configure the security admin configuration to modify the Zero trust rules set for the network group of which your virtual network is a member, go to your VM’s NSG --> Under ‘Support + Troubleshooting’, select ‘Effective security rules’, in that check the name of the ‘Associated Azure Network Manager’ and select it, then select the ‘Configurations’ option under ‘Settings’, in that check the security configuration rule collection set and modify the rules or remove them from that collection set and save it. Once done, you should be able to access the VM over RDP and the SQL Server over its ports. In this way, you can modify the ‘Zero Trust’ network configuration rules for a VM.
Please find the below snapshot of the above said settings in my tenant: -
Please note that you need to have ‘Subscription Admin’ permissions to configure and modify the network manager settings. Also, refer to the below article for detailed configuration and deployment of Azure Virtual network Manager: -
https://virtualizationreview.com/articles/2021/11/03/azure-virtual-network-manager.aspx
How can I monitor the authentication logs on the Google cloud platform?
For example, to check if someone has tried to make unauthorized access.
With Admin Activity audit logs you will be able to answer the questions of "who did what, where, and when?" within your Google Cloud resources. It provides the following audit logs for each Cloud project, folder, and organization:
Admin Activity audit logs
Data Access audit logs
System Event audit logs
Policy Denied audit logs
You can obtain more information on Cloud Audit Logs, It will be useful to see all the events that happen into your projects, but it might not be useful for the information you want to see.
Nevertheless, there is a tool Event Threat Detection that uses log data from inside your systems and when a threat is detected, Event Threat Detection writes a Finding to Security Command Center and to a Cloud Logging project.
For example:
Event Threat Detection detects brute force of password authentication SSH by examining syslog logs for repeated failures followed by a success.
But this feature is available only for Security Command Center Premium tier.
On the other hand you mentioned that you have some VM instances and want to prevent attacks.
I recommend you to check the following documentation: Securely connecting to VM instances
There are several methods for protecting services on VMs with external IP addresses explained in this document, including Firewalls, HTTPS and SSL, port forwarding over SSH, and SOCKS proxy over SSH.
For example, by creating firewall rules, you can restrict all traffic to a network or target machines on a given set of ports to specific source IP addresses.
We're unable to start our JVMs after changing the LDAP server in the Security -> Global Security settings. We get "The user is from a foreign realm, XXXX:289, and this foreign realm is not trusted. Current realm is XXXX".
This error seems straightforward. Yet we cannot find anything wrong with our settings. The "Trusted authentication realms - inbound" looks correct. The settings in the Global Security looks right. The users have been recreated
The process we followed was to update the LDAP server. Remove and added back the Admin group roles so they have the new LDAP server. Then shutdown all the Websphere processes. Run the osgiCfgInit.sh and clearcasecache.sh scripts to clear the cache. Then started the processes back up.
Is there a file or cache we need to modify for our admin user?
When using a Bamboo cloud agent, on Windows, you're instructed to have a Bamboo Windows user with a default known password: Atlassian1.
It clearly says that this user should be configured to denied remote login.
But still, it's an active Windows user with a fair bit of permissions. Bamboo's server (cloud) interacts with the machine in a known port - 26224. Through this channel it sends all build commands, get build status from the remote agent etc.
What prevents a hacker from scanning the Internet, find a host with port 26224 open and start talking with the Bamboo agent? How does the agent know for sure that it talks to a legitimate Bamboo CI server?
I'm asking that in order to be fully confident that there is no possible attack vector.
The Security documentation for Bamboo states:
Please note the following security implications when enabling remote agents for Bamboo:
No encryption of data passed between server and agent — this includes data such as:
login credentials for version control repositories
build logs
build artifacts
No authentication of the agent or server — this could result in unauthorised actions being taken on your system, such as:
Unauthorised parties installing new remote agents — version control repository login credentials could be stolen.
Unauthorised parties masquerading as a Bamboo server — the unauthorised server could pass malicious code to the agent to run.
See Agent authentication for more information.
We strongly recommend that you do not enable remote agent installation on any Bamboo instance accessible from a public or untrusted network. Creating remote agents is Disabling and enabling remote agents support by default.
For public facing agents, Atlassian strongly recommends securing them which is done using SSL. See Securing your remote agents which contains this note:
This page applies to remote agents and not elastic agents. Elastic agents are secured automatically by the Bamboo server and no additional steps are required.
Further more to the Elastic Piece, their documentation on Elastic Bamboo Security states:
All traffic sent between the agents located in EC2 and the Bamboo server is tunnelled through an SSL-encrypted tunnel. The tunnel will be initiated from the Bamboo Server to the EC2 instance, which means that you don't need to allow any inbound connections to your server. You will need to permit outbound traffic from the server on the tunnel port, however - the default port number is 26224. On the EC2 instance, only the tunnel port needs to be open for inbound traffic.
I've been reading about how you should set specific service accounts to each sql service, but from what i've read, none have been detailed enough on how to properly create one, would anyone mind explaining what would be the steps on how to create a local, low permission account for the sql service on windows?
Some basic information is available at http://msdn.microsoft.com/en-us/library/cc281953.aspx
I tend to make domain user accounts with no particular rights on the network apart from what the account would normally receive (eg domain users). During SQL Server installation you provide these accoounts to the SQL installer - it will correctly configure the accounts for you (adding them to certain groups, etc).
If you're doing it after SQL installation the correct way to change the service account is to use the SQL Server Configuration Manager (in your start menu) as it will ensure the accounts are, once again, correctly configured.
Using domain accounts is great as you can then grant the service accounts access to particular network shares (backups) and other database servers (linked servers, etc).
As an additional measure if your network resources (file shares, etc) are secured using custom made security groups, rather than "domain users", your SQL Server services won't have access to these areas of the network they shouldn't be able to reach. I personally haven't tried removing the "domain users" membership - you can't break anything by giving it a go on a VM? :)
This site describes the different options to use the least privileges and the danger of the other options:
WHEN TO USE DOMAIN USER ACCOUNT?
WHEN TO USE NETWORK SERVICE ACCOUNT?
WHEN TO USE LOCAL USER ACCOUNT?
WHEN TO USE LOCAL SYSTEM ACCOUNT?
-
-
http://goo.gl/vG55n