Transient fault handling in gRPC with retries in C#

gRPC calls can be interrupted by transient faults. Transient faults include:

  • Momentary loss of network connectivity.
  • Temporary unavailability of a service.
  • Timeouts due to server load.

When a gRPC call is interrupted, the client throws an RpcException with details about the error. The client app must catch the exception and choose how to handle the error.

var client = new Greeter.GreeterClient(channel);
try
{
    var response = await client.SayHelloAsync(
        new HelloRequest { Name = ".NET" });

    Console.WriteLine("From server: " + response.Message);
}
catch (RpcException ex)
{
    // Write logic to inspect the error and retry
    // if the error is from a transient fault.
}

Duplicating retry logic throughout an app is verbose and error-prone. Fortunately, the .NET gRPC client now has built-in support for automatic retries. Retries are centrally configured on a channel, and there are many options for customizing retry behavior using a RetryPolicy.

var defaultMethodConfig = new MethodConfig
{
    Names = { MethodName.Default },
    RetryPolicy = new RetryPolicy
    {
        MaxAttempts = 5,
        InitialBackoff = TimeSpan.FromSeconds(1),
        MaxBackoff = TimeSpan.FromSeconds(5),
        BackoffMultiplier = 1.5,
        RetryableStatusCodes = { StatusCode.Unavailable }
    }
};

// Clients created with this channel will automatically retry failed calls.
var channel = GrpcChannel.ForAddress("https://localhost:5001", new GrpcChannelOptions
{
    ServiceConfig = new ServiceConfig { MethodConfigs = { defaultMethodConfig } }
});

References
https://devblogs.microsoft.com/dotnet/grpc-in-dotnet-6/
https://docs.microsoft.com/en-us/aspnet/core/grpc/retries?view=aspnetcore-6.0

gRPC client-side load balancing in C#

The following code example configures a channel to use DNS service discovery with round-robin load balancing:

var channel = GrpcChannel.ForAddress(
    "dns:///my-example-host",
    new GrpcChannelOptions
    {
        Credentials = ChannelCredentials.Insecure,
        ServiceConfig = new ServiceConfig { LoadBalancingConfigs = { new RoundRobinConfig() } }
    });
var client = new Greet.GreeterClient(channel);

var response = await client.SayHelloAsync(new HelloRequest { Name = "world" });

References
https://devblogs.microsoft.com/dotnet/grpc-in-dotnet-6/
https://docs.microsoft.com/en-us/aspnet/core/grpc/loadbalancing?view=aspnetcore-6.0

Parallel.ForEachAsync in .NET 6

using System.Net.Http.Headers;
using System.Net.Http.Json;

var userHandlers = new []  { "users/VahidN", "users/shanselman", "users/jaredpar", "users/davidfowl" };

using HttpClient client = new()
{
    BaseAddress = new Uri("https://api.github.com"),
};
client.DefaultRequestHeaders.UserAgent.Add(new ProductInfoHeaderValue("DotNet", "6"));

ParallelOptions parallelOptions = new() { MaxDegreeOfParallelism = 3 };

await Parallel.ForEachAsync(userHandlers, parallelOptions, async (uri, token) =>
{
    var user = await client.GetFromJsonAsync<GitHubUser>(uri, token);
    Console.WriteLine($"Name: {user.Name}\nBio: {user.Bio}\n");
});

public class GitHubUser
{
    public string Name { get; set; }
    public string  Bio { get; set; }
}

References
https://www.hanselman.com/blog/parallelforeachasync-in-net-6

Move an Application Window From Off-screen Back to Your Main Desktop

  1. Right-click on the Windows taskbar and select Cascade windows from the pop-up menu.
  2. Hold down the Shift key, then right-click on the appropriate application icon in the Windows taskbar.
  3. On the resulting pop-up, select the Move option.
  4. Begin pressing the arrow keys on your keyboard to move the invisible window from off-screen to on-screen. Typically, you will use the left arrow to move the window from right to left.

References
https://support.ti.davidson.edu/hc/en-us/articles/115016089728-Move-an-Application-Window-From-Off-screen-Back-to-Your-Main-Desktop-Windows

Use GPUpdate /Force Command to update your Group Policies

The command gpupdate /force is used to force the update of group policies that are applied by your company. Changes made in the Group Policy are not applied immediately but after 90 mins by default (with a ~30 min offset to spread the load). By using the GPUpdate command we can force the update.

Group Policies are used to change security settings and for system management (like deploying printers or mapping network drives). For troubleshooting IT problems, it’s sometimes necessary to update the group policy manually.

How force group policy update

  1. Press Windows key + X or right-click on the start menu

  2. Select Windows PowerShell or Command Prompt

3. Type gpupdate /force and press enter

Wait for the Computer and User policy to update

4. Reboot your computer

A reboot is necessary to be sure that all settings are applied.

GPUpdate vs GPUpdate Force command

The gpupdate /force command is probably the most used group policy update command. When you use the /force switch, all the policy settings are reapplied. For most use cases this is perfectly fine, but keep in mind, when you have a lot of group policies objects (GPO) or in a large environment, using the /force will put a huge load on the domain controllers.

If you have a large tenant or a lot of GPO’s, then it’s better to only run gpupdate without the /force switch to apply new policy settings. This will get only the changes or new group policies, reducing the load on the client and domain controllers.

# Reapply all policies
gpupdate /force
# Get only the changed / new group policies
gpupdate

Update only user or computer group policies

If you have a large environment or need to update the group policies on a lot of computers at the same time, then it can be useful to only update what is needed. This will reduce the load on the domain controllers and it’s of course faster.

To do this you can use the /target switch. This allows you to update only the user or computer GPO’s.

# Update only the user policies
gpupdate /target:user
# Update only the computer policies
gpupdate /target:computer

Automatically reboot or logoff after GPUpdate

Not all policy changes are applied immidiately. Due to Fast Boot, for example, are some settings only applied when the users logs in on the computer. Some settings even require a reboot to be applied.

With the use of the /logoff or /boot switch, we can let gpupdate figure out if a logoff or reboot is necessary. To be clear, if you run gpupdate /boot, then the computer will only reboot if a policy change requires it. Otherwise, the policy will be applied immediately without the reboot.

  • GPUpdate /logoff is needed for example after policy changes in the Active Directory like folder redirections or printers. Changes in the AD are only applied when the user logs in on the computer.
  • GPUpdate /boot is for example needed when you create Software Distribution changes.

Run GPUpdate on a Remote Computer

Sometimes you may need to update quickly the group policies on multiple computers because you changed the internet proxy settings or maybe to replace a printer for example. There are couple of ways to run GPUpdate on a remote computer

Using the Group Policy Management Console

You can initiate a group policy update on a whole OU with the Group Policy Management Console. It has to be an OU with only computer objects in it, so you can’t use the method on a user OU. Simply right-click on the OU where you have changed a policy and click on Group Policy Update

This will update the user and computer policies on all the computers in the given organization unit. The nice thing is that it will as for confirmation and show you how many computers are going to be updated.

After you have confirmed the update the policies will be updated and you can see the status of each computer. In this example 5 computers where turned off, so the update failed.

References
https://lazyadmin.nl/it/gpupdate-force-command/

NTFS Permissions vs Share

One of the most critical security concepts is permissions management: ensuring that proper permissions are set with users – and that usually means knowing the difference between share and NTFS permissions.

Share and NTFS permissions function completely separately from each other, but ultimately serve the same purpose: to prevent unauthorized access.

However, when NTFS and share permissions interact or when a shared folder is in a separate shared folder with different share permissions, users might not be able to access their data or they can get higher levels of access than security admins intend.

Here are key differences between share and NTFS permissions so you’ll know what to do.

What is NTFS?

A file system is a way of organizing a drive, indicating how data is stored on the drive and what types of information can be attached to files, such as permissions and file names.

NTFS (NT File System) stands for New Technology File System (NTFS). NTFS is the latest file system that the Windows NT operating system uses for storing and retrieving files. Prior to NTFS, the file allocation table (FAT) file system was the primary file system in Microsoft’s older operating systems, and was designed for small disks and simple folder structures.

NTFS file system supports larger file sizes and hard drives and is more secure than FAT. Microsoft first introduced NTFS in 1993 with the release of Windows NT 3.1. It is the file system used in Microsoft’s Windows 10, Windows 8, Windows 7, Windows Vista, Windows XP, Windows 2000, and Windows NT operating systems.

NTFS Permissions

NTFS permissions are used to manage access to the files and folders that are stored in NTFS file systems.

To see what kind of permissions you will be extending when you share a file or folder:

  • Right click on the file/folder
  • Go to “Properties”
  • Click on the “Security” tab

All then you’ll navigate this window:

Besides Full Control, Change, and Read that can be set for groups or individually, NTFS offer a few more permission options:

  1. Full control: Allows users to read, write, change, and delete files and subfolders. In addition, users can change permissions settings for all files and subdirectories.
  2. Modify: Allows users to read and write of files and subfolders; also allows deletion of the folder.
  3. Read & execute: Allows users to view and run executable files, including scripts.
  4. List folder contents: Permits viewing and listing of files and subfolders as well as executing of files; inherited by folders only.
  5. Read: Allows users to view the folder and subfolder contents.
  6. Write: Allows users to add files and subfolders, allows you to write to a file.

If you’ve ever involved in permissions management within your organization, you’ll eventually encounter ‘broken’ permissions. Rest assured, they’re repairable.

Share Permissions

When you share a folder and want to set the permissions for that folder – that’s a share. Essentially, share permissions determine the type of access others have to the shared folder across the network.

To see what kind of permissions you will be extending when you share a folder:

  • Right click on the folder
  • Go to “Properties”
  • Click on the “Sharing” tab
  • Click on “Advanced Sharing…”
  • Click on “Permissions”

And you’ll navigate to this window:

There are three types of share permissions: Full Control, Change, and Read.

  1. Full Control: Enables users to “read,” “change,” as well as edit permissions and take ownership of files.
  2. Change: Change means that user can read/execute/write/delete folders/files within share.
  3. Read: Read allows users to view the folder’s contents.

A Caveat on Share Permissions

Sometimes, when you have multiple shares on a server which are nested beneath each other, permissions can get complicated and messy.

For instance, if you have a “Read” folder in a subfolder share permission but then someone creates a “Modify” share permission above it at a higher root, you may have people getting higher levels of access then you intend.

There’s a way around this, which I’ll get to below.

How to Use Share and NTFS Permissions Together

One of the common questions that comes up when you’re configuring security is “what happens when share and NTFS permissions interact with each other?”

When you are using share and NTFS permissions together, the most restrictive permission wins.

Consider the following examples:

If the share permissions are “Read”, NTFS permissions are “Full control”, when a user accesses the file on the share, they will be given “Read” permission.

If the share permissions are “Full Control”, NTFS permissions are “Read”, when a user accesses the file on the share, they will still be given a “Read” permission.

Managing NTFS Permissions and Share Permissions

If you find working with two separate sets of permissions to be too complicated or time consuming to manage, you can switch to using only NTFS permissions.

When you look at the examples above, with just three types of permissions setting, shared folder permissions provide limited security for your folders. Therefore, you gain the greatest flexibility by using NTFS permissions to control access to shared folders.

Moreover, NTFS permissions apply whether the resource is accessed locally or over the network.
To do this, change the share permissions for the folder to “Full Control.”

You can then make whatever changes you want to the NTFS permissions without having to worry about the share permissions interfering with your changes.

References
https://www.varonis.com/blog/ntfs-permissions-vs-share/

Authenticated Users vs Domain Users

Both are built-in groups introduced in windows to control security of objects like user,computer and service account at different level. 

Authenticated Users

The Authenticated Users group contains users who have authenticated to the domain or a domain that is trusted by the computer domain. Authenticated Users will contain all manually created user accounts in all trusted domains regardless of whether they are a member of the Domain Users group or not.  Authenticated Users specifically does not contain the built-in Guest account, but will contain other users created and added to Domain Guests.

The following list shows the members who are fall under this group

  1. All the domain users and  users who are in trusted domain.
  2. Local computers.
  3. Built-in system accounts.

The local computer account is always a member of the Authenticated Users group even when disconnected from the network.  However, just like Domain Users, the local computer account must first authenticate to the domain to be considered part of the Authenticated Users token when connecting remotely to other computers within its trusted domains.

The SID for Authenticated Users is S-1-5-11.  Authenticated Users is available when applying permissions directly to an object, or can be placed in Built-in and user created Local computer groups.  Authenticated Users cannot be added as a member to another user created domain groups (Global, Domain Local, or Universal).  However, the Authenticated Users group can be added to the Built-in Domain Local groups.

When working with domain user accounts and local user accounts remember that the local user accounts will also be members of Authenticated Users, and will therefore have access to local resources secured with this permission.  However, the scope of the local user accounts’ access will not extend onto remote computers via the Authenticated Users group.  This is because while the local user account includes the SID for the Authenticated User group, the local user must still authenticate to any remote computer prior to access being granted.

 Recommendation for Security: Use the Authenticated Users group instead of the Everyone group to prevent anonymous access to a resource.

Domain Users

Domain Users is the group in which we can add or remove members that we can not do in Authenticated Users group . In a domain environment, the Administrator account and all new user accounts are automatically included as members of this group. This group is also a member of the Users local group for the domain and for every Windows computer in the domain

By default all users created in the domain are automatically members of this group.  However, the default Guest account in the domain is not a member of this group, instead it is placed in the Domain Guest group

The SID for Domain Users is S-1-5-<domain>-513.  The Domain Users group can be added to other domain groups, and can be given permissions directly to objects, as well as placed in Local computer groups.

You can refer this article http://technet.microsoft.com/en-us/library/dd277461.aspx to know about other built-in groups.

References
https://morgantechspace.com/2013/08/authenticated-users-vs-domain-users.html