I'm testing using a gMSA account to run an SF app, instead of NETWORKSERVICE.
Following the instructions from here:
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-application-runas-security
Created the gMSA on the domain controller using the powershell cmdlet:
New-ADServiceAccount -name MySA$ -DnsHostName MySA.contoso -ServicePrincipalNames http/MySA.contoso -PrincipalsAllowedToRetrieveManagedPassword Node0Machine$, Node1Machine$, Node2Machine$
Install-AdServiceAccount returned an "unspecified error" on each of the nodes, however Test-AdServiceAccount returns true for MySA$ (when running powershell as a domain user)
ApplicationManifest.xml has the following changes:
<Principals>
<Users>
<User Name="MySA" AccountType="ManagedServiceAccount" AccountName="Contoso\MySA$"/>
</Users>
</Principals>
<Policies>
<SecurityAccessPolicies>
<SecurityAccessPolicy ResourceRef="ConfigurationEncipherment" PrincipalRef="MySa" ResourceType="Certificate" />
</SecurityAccessPolicies>
<DefaultRunAsPolicy UserRef="MySA"/>
</Policies>
The Service Fabric explorer shows the following error for each service:
Error event: SourceId='System.Hosting', Property='CodePackageActivation:Code:SetupEntryPoint'.
There was an error during CodePackage activation.Service host failed to activate. Error:0x8007052e
I have also tried creating the cluster using the gMSA (we are using X509 successfully at the moment). Using the gMSA cluster config as a template, it fails with a timeout (presumably the "WindowsIdentities section is incorrect - there seems to be little documentation on this)
"security": {
"WindowsIdentities": {
"ClustergMSAIdentity": "MySA$#contoso",
"ClusterSPN": "http/MySa.contoso",
"ClientIdentities": [
{
"Identity": "contoso\\MySA$",
"IsAdmin": true
}
]
},
The Error:0x8007052e may be linked to a logon failure.
According to Secure a standalone cluster on Windows by using Windows security and Connect to a secure cluster
If you have more than 10 nodes or for clusters that are likely to grow or shrink. Microsoft strongly recommend using the Group Managed Service Account (gMSA) approach.
You will see also:
You can establish trust in two different ways:
Specify the domain group users that can connect.
Specify the domain node users that can connect.
[...]
Administrators have full access to management capabilities (including read/write capabilities). Users, by default, have only read access to management capabilities (for example, query capabilities), and the ability to resolve applications and services.
You may also find help on Getting Started with Group Managed Service Accounts
According to your comment, as soon as you add the gMSA to the ServiceFabricAdministrators group everything will work and it is probably due to the fact that "administrators have full access to management capabilities"
Related
(I'm afraid I'm probably about to reveal myself as completely unfit for the task at hand!)
I'm trying to setup a Redshift cluster and database to help manage data for a class/group project.
I have a dc2.large cluster running with either default options, or what looked like the most generic in the couple of place I was forced to make entries.
I have downloaded Aginity (Win64) as it is described as being specialized for Redshift. That said, I can't find any instructions for connecting using it. The connection dialog requests the follwoing:
Server: using the endpoint for my cluster (less :57xx at the end).
UserID: the Master username for the database defined for the cluster.
Password: to match the UserID
SSL Mode (Disable, Allow, Prefer, Require): trying various options
Database: as named in cluster setup
Port: as defined in cluster setup
I can't get it to connect ("failed to establish connection") and don't know if I'm entering something wrong in Aginity or if I haven't set up my cluster properly.
Message: Failed to establish a connection to 'abc1234-smtm.crone7m2jcwv.us-east-1.redshift.amazonaws.com'.
Type : Npgsql.NpgsqlException
Source : Npgsql
Trace : at Npgsql.NpgsqlClosedState.Open(NpgsqlConnector context, Int32 timeout)
at Npgsql.NpgsqlConnector.Open()
at Npgsql.NpgsqlConnection.Open()
at Aginity.MPP.Common.BaseDataProvider.get_Connection()
at Aginity.MPP.Common.BaseDataProvider.CreateCommand(String commandText, CommandType commandType, IDataParameter[] commandParams)
at Aginity.MPP.Common.BaseDataProvider.ExecuteReader(String commandText, CommandType commandType, IDataParameter[] commandParams)
--- Inner Exception: ---
......
It seems there is not enough information going into Aginity to authorize connection to my cluster - no account credential are supplied. For UserID, am I meant to enter the ID of a valid user? Can I use the root account? What would the ID look like? I have setup a User with FullAccess to S3 and Redshift, then entered the UserID in this format
arn:aws:iam::600123456789:user/john
along with the matching password, but that hasn't worked either.
The only training/tutorial I have been able to find/do on this is the Intro AWS direct you to, at https://qwiklabs.com/focuses/2366, which uses a web-based client that I can't find outside of the tutorial (pgweb).
Any advice what I am doing wrong, and how to do it right?
Well, I think I got it working - I haven't had a chance to see if I can actually create table yet, but it seems to be connected. I had to allow inbound traffic from outside the VPC, as per the above snapshot.
I'm guessing there's a better way than opening it up to all IP addresses, but I don't know the users' (fellow team members) IPs, and aren't they all subject to change depending on the device they're using to connect?
How does one go about getting inside the VPC to connect that way, presumably more securely?
I want to delete an AWS VPC which I don't know how it came into existence. When I try to delete it in AWS Console, it says:
We could not delete the following VPC (vpc-0a72ac71) Network interface
'eni-ce2a0d10' is currently in use. (Service: AmazonEC2; Status Code:
400; Error Code: InvalidParameterValue; Request ID:
821d8a6d-3d9b-4c24-b372-314ea9b18b23)
As it mentions "AmazonEC2" in the error message, I suspected there might be some EC2 instances residing in this VPC. So I went into EC2 dashboard but found no EC2 exist there. However, I found there are two security groups associated with this vpc. So I decided to delete them hoping that's the cause of the error. But when I tried to do so, I got this message:
As the message says, these security groups are associated with some network interfaces. Therefore, I decided to 'Detach' those but I got this error message:
Error deleting network interfaces eni-ce2a0d10: You do not have
permission to access the specified resource. eni-0b7ff712: You do not
have permission to access the specified resource.
But I'm the root user so I assume I should be able to do whatever I want to do except if the resource is made by aws itself or another root account.
I know somewhere this network interface is being used but it will be very time-consuming to go through each aws service and check that.
I've already checked AWS RDS service and no instance or rds subnet is made.
I've already checked this question and this with no luck.
I found the root cause of this issue.
Short Answer:
That VPC was created solely for the WorkDocs service instance. So AWS was preventing me to delete its VPC and any of its dependent services and pieces.
How I figured it out:
First, I noticed something interesting has been written in the 'Description' column of the 'undeletable' Network Interfaces (you can see them in the last OP's figure):
"AWS created network interface for directory d-90672d6b72."
From "directory", I suspected that this might have something do to with AWS Directory Service. So I went to this service and noticed there is a directory associated with the VPC:
So I tried to remove this directory but I got this error message:
Error - Directory cannot be deleted This directory still has
authorized applications, and cannot be deleted. To delete this
directory, complete all of the following steps: • Delete the WorkDocs
site attached to this directory.
Therefore, I went to AWS WorkDocs Service and found it and deleted it:
So now the directory is also deleted (circled in red), I went back to delete those network interfaces. However I realized that they are vanished! (I guess Amazon removed them on its own). I went to VPC service to see whether I'm now able to delete the VPC. Guess what? That VPC was vanished too!
Now I understand what was happening. That VPC was created solely for the WorkDocs service instance. I wish Amazon was more transparent about it.
As a more generic answer to the "Error deleting network interface" issue, it happens when a network interface was created automatically for a higher-level AWS resource.
The Generic solution is to manage the network interface in the higher level resource directly such as WorkDocs or EFS.
In my case it happened when I wanted to delete a security group assigned to network interfaces created by an EFS volume.
So I went in the EFS console and removed the security group from the EFS.
When opening a sql connection to a local database in a traditional console app I have no issues, however when I attempt to do the same thing within a stateless service running in Service Fabric I get a login error.
The error I receive is "Login failed for user 'WORKGROUP\\NICK$'."
And this is the code I'm using to connect
using (var con = new SqlConnection("Server=.;Trusted_Connection=True;Database=AddressBook"))
{
try
{
con.Open();
}
catch (Exception e)
{
}
}
When I try to add that user to sql server it tells me that the user cannot be found.
Based on the comments above I learned that Service Fabric is running under the NETWORK SERVICE account.
The solution is to update the User Mapping and role membership for the databases that you want to access within the SF cluster.
In SSMS expand Security, Logins, right click NETWORK SERVICE and then choose properties. Under User Mapping place a checkbox next to each Database that you want to expose access to and down below public, db_datareader/writer.
A comment to the accepted answer mentions running your service as a different user account. Here's how to do that. In your ApplicationManifest.xml file, insert this:
<Principals>
<Users>
<User Name="AcctToUse" AccountType="DomainUser"
AccountName="MyDomain\MyUsername" Password="MyPassword" />
</Users>
</Principals>
<Policies>
<DefaultRunAsPolicy UserRef="AcctToUse" />
</Policies>
Edit: I didn't make it clear, AcctToUse is just a string that you make up. It's a key that points to the User. The AccountName field on the other hand is the username.
How do I change settings for a deployed application in Service Fabric?
I have a provisioned cluster and an application deployed to the cluster with two applications. I would like to be able to change my services' settings and have them pick up those changes, but I don't see how I can do that.
Previously, we've done all of our services with worker roles in Cloud Services, and the portal allows for changing configurations, but it does not appear to do so for Service Fabric. From the Service Fabric Explorer I can drill down to the service, go to MANIFEST and view the XML with the settings. I just don't see a way to edit or change it. I've struggled finding anything in the SF documentation addressing this.
The portal doesn't expose a way to do this. It needs to be done via an upgrade of the application. Just change the settings in your settings XML file and perform an upgrade. In the VS publish dialog for your application project, you can update your version numbers appropriately by changing the config package version which will automatically bubble up to update the containing service and application versions.
Building on Matt Thalman's answer, here's documentation on modifying the settings in the application or service manifest XML files, updating the version numbers, and performing an application upgrade: Service Fabric application upgrade tutorial using Visual Studio. You can also perform the app upgrade using PowerShell.
Additional to above answers, adding some powershell code..
we may use below powershell code to connect to Service Fabric from powershell and get the application parameters and then update specific parameter and re deploy..
### Change the connection here (from Profile-Cloud.xml
$ConnectArgs = #{
ConnectionEndpoint="devxxxxxx.westus.cloudapp.azure.com:19000"
X509Credential="true"
ServerCertThumbprint="52BFxxxxxxxxxx"
FindType="FindByThumbprint"
FindValue="EF3A2xxxxxxxxxxxxxx"
StoreLocation="CurrentUser"
StoreName="My"
}
Connect-ServiceFabricCluster #ConnectArgs
$myApplication = Get-ServiceFabricApplication -ApplicationName fabric:/ABC.MyService
$appParamCollection = $myApplication.ApplicationParameters
### Update your parameter here..
$applicationParameterMap.ElasticSearch_Username="sachin2"
$applicationParameterMap = #{}
foreach ($pair in $appParamCollection)
{
$applicationParameterMap.Add($pair.Name, $pair.Value);
}
### Start Udpating
Start-ServiceFabricApplicationUpgrade -ApplicationName $myApplication.ApplicationName.OriginalString -ApplicationTypeVersion $myApplication.ApplicationTypeVersion -ApplicationParameter $applicationParameterMap -Monitored -FailureAction Rollback -ForceRestart $true
### Check the status until it is Ready
(Get-ServiceFabricApplication -ApplicationName fabric:/ABC.MyService).ApplicationStatus
### Check the parameters to confirm those're updated
Get-ServiceFabricApplication -ApplicationName fabric:/ABC.MyService
You may change or remove the -ForceRestart as per your requriements
I have followed the instructions at https://github.com/cloudfoundry/oss-docs/tree/master/vcap/adding_a_system_service and copied the echo service and created my new service. (That document is somewhat out-of-date in that "excluded components" no longer exists.
In any case, my service shows up as running with a gateway and a node when I look at 'vcap status' on the server. However, when I look at 'vmc services' from the client my service is not in the list. Where is this list maintained and why is my service not on the list?
Various services, including blob, filesystem, mongodb, etc, are shown on the 'vcm services' list even though they have never been included in my config. Where is this maintained and why are other services on this list?
The cloud_controller.log file shows a "Create service request:" for echo every minute. This service is not in my config file (it was once but it was removed and I repeated the deployment). What is prompting this request for a service that was not defined in the config?
The _gateway.log for my service shows the following:
INFO -- Sending info to cloud controller: ...api.vcap.me/services/v1/offerings
INFO -- Fetching handles from cloud controller .../offerings/.../handles
ERROR -- Failed registering with cloud controller, status=400
DEBUG -- [GaaS-Provisioner] Connected to node mbus..
ERROR -- Failed fetching handles, status=404
Why does my gateway fail to register with the cloud controller? I have found some reports that suggest that the problem is with domain name mapping. I have verified that the server can find itself:
$curl api.vcap.me
Welcome to VMware's Cloud Application Platform
What can I do to register my service?
You can also try asking your question on the vcap_dev google group.
https://groups.google.com/a/cloudfoundry.org/forum/?fromgroups#!forum/vcap-dev
They are focused in answering and discussing OSS subjects for Cloud Foundry!
If you follow the document correctly things should work just fine. I understand that the mechanism for maintaining the excluded list of components has changed and can be a point of confusion when following the steps mentioned in the article (just ignore that step totally).
ERROR -- Failed registering with cloud controller, status=400
Well this is a point of worry. I recently followed the article step by step and was able to add a new service.
Is the echo service showing up in vmc services?
Have you copied the the yml files for node and gateway at ./cloudfoundry/.deployments/devbox/config?
Are the tokens for your gateway unique? and matching in the two files? ./cloudfoundry/.deployments/devbox/config/cloud_controller.yml and ./cloudfoundry/.deployments/devbox/config/**_gateway.yml**
I would recommend that you first concentrate on getting the echo service to be listed in the vmc services output. Once done with this you should replicate the steps (with absolute care to modify things like the token) to get your custom service working.
Cheers,
Ankit
You should follow this guide
It work to me.
regards.