Terminologies used in Active Directory Federation Services (ADFS)

Here is a list of the different terminology that is used with Federation Services. This will give you a good indication of what components make up a Federation Service in Active Directory Federation Services and other Federation services.

(ADFS key concept- Image source: acbrownit.com)

• Account Partner Organization

This contains the user accounts that will access the Federation Service. In some cases this may be a domain in other cases it may be a database or simply an e-mail address. The important point to remember is that these are the users that will access Federation Services. This will contain information like their usernames, password, and other details about the user.

• Resource Partner Organization

A resource partner organization contains the resources that are accessed by the Federation Service Users. Normally this will be external to the company, but in some cases may be on a DMZ of the company. A resource partner could also be in a cloud-based application. For example, MS Office products located in the cloud.

• Federation Trust

A Federation Trust is a trust between different parts of Federation Services. An example is the trust between the Account Partner Organization and Resource Partner Organization. The trust is not a connection style trust and thus when created does not require communication to happen over the trust. The trust does not require a direct connection between the two Federation Servers, however, it is often simpler to have a connection between the two so that the Federation Server can obtain information that it requires in order to create the trust.

• Claim

A claim is essentially a statement about a user. When the claim is created, it will need to be created with the information required by the other side. This may include information about what services they require. This may also contain information about groups they are in. The Federation Server creating the claim needs to ensure all this information is put into the claim. The claim is essentially a file that is then transferred to the other party. In a lot of cases, the user may request the claim from their Federation Server and then present this claim to the Federation Server that is providing the service.

• Claims Provider Trust

Active Directory Federation Services has two types of trusts that are used. The first trust is a Claims Provider Trust. A Claims Provider Trust accepts claims. So essentially this trust defines who and how the trust can be used.

• Relying Party Trust

A Relying Party Trust is used to create claims. Once a claim is created it is supplied to a Claims Provider Trust. A Relying Party Trust is required in the account partner organization to create claims that will be used in the Resource Partner Organization. A relying party trust is also used to access resources. For example, if the Active Directory Federation Services needs to access an application or Domain Services.

• Claim Provider

A claims provider is an organization that provides claims for users. These claims are normally used by Claims Aware applications that can be in the domain, external domain, or in the cloud.

• Federation Server

This is a server that is running Federation Services. In the case of Windows, this will be Active Directory Federation Services.

• Account Federation Server

An Account Federation Server provides security tokens that contain claims. These are given to the user. In order to do this, the account Federation Server must get this information from somewhere.

• Attribute Store

An attribute store contains information about the user. This can be stored in Active Directory Domain Services, SQL Server, or Active Directory Light Weight Directory Services. This does not provide authentication. For example, a Domain Controller could be used to authenticate the user, and then the attribute store could be used to get additional information about the user. For example, the attribute store may contain a picture of the user.

• Federation Metadata

This is the configuration information for the Federation Server. When creating a trust, data is required about the other server in order to create the trust. This data can be entered manually however this is time-consuming to do. When creating the trust, you have the option to use the Metadata. This Metadata can be obtained through a direct connection between the two servers. If this is not available, the data can be exported and any method can be used to get the data from one server to the other server.

Metadata URL: https://<hostname>/federationmetadata/2007-06/federationmetadata.xml.

• AD FS Configuration Database

This stores the configuration that is used by Active Directory Federation Services. This can be on the SQL server or Windows Internal Database.

• Primary Federation Server

This is the first server that is set up in a farm. It holds a read/write copy of the database. All the other servers in the farm contain a read-only copy of the database. These servers need to replicate changes to the read/write copy of the database

• Federated User

This is a user that has been given a claim. The claim can then be used on another server to gain access to a resource.

• Relying Party

A relying party is an organization that receives a claim. In most cases, this will be the resource partner organization.

• Resource Federation Server

This is a Federation Server in the resource partner organization that accepts claims. When a claim is presented to the server, the server will create a new claim and give this to the user. This claim contains information like what resources they are allowed to access.

• Claims-Aware Application

This is an application that can accept claims to provide access to an application. For example, MS Office is capable of accepting claims.

Windows Administrator Interview FAQs -L3 Level

Frequently Asked Interview Questions for Windows Administrator Role

1. What is a memory leak?

Memory leaks are class of bugs where the application fails to release memory when no longer needed. A memory leak occurs when a process allocates memory from the paged or nonpaged pools but does not free the memory. As a result, these limited pools of memory are depleted over time, causing Windows to slow down. If memory is completely depleted, failures may result.

2. What tools are used to check memory leak?

• Performance Monitor and Resource Monitor are part of Windows Server /client OS and can monitor and graph resource use over time
• The latest version of Application Verifier can diagnose heap leaks on Windows 
• UMDH, which is part of the Debugging Tools for Windows, analyzes the heap memory allocations for a given process and can help find leaks and other unusual usage patterns
• Xperf is a sophisticated performance analysis tool with support for heap allocation traces
• CRT (C Run-Time) Debug Heap tracks heap allocations and can help build your heap debugging features.
• Microsoft’s DebugDiag (Memory Pressure Analyzer)

3. How to use Umdh.exe to find memory leaks (Umdhtools.exe)?

The user-mode dump heap (UMDH) utility works with the operating system to analyze Windows heap allocations for a specific process. This utility, and the other tools associated with it, are primarily targeted for legacy Windows versions.

4. How performance monitor is used to check memory leak?

Performance Monitor can be used to determine whether a leak exists. If you suspect that a particular application or service is causing a memory leak, investigate the memory use of your applications using the following counters:

• Memory\Available Bytes reports available bytes; its value tends to fall during a memory leak.
• Memory\Committed Bytes reports the private bytes committed to processes; its value tends to rise during a memory leak.
• Process( process_name )\Private Bytes reports bytes allocated exclusively for a specific process; its value tends to rise for a leaking process.
• Process( process_name )\Working Set reports the shared and private bytes allocated to a process; its value tends to rise for a leaking process.
• Process( process_name )\Page Faults/sec reports the total number of faults (hard and soft faults) caused by a process; its value tends to rise for a leaking process.
• Process( process_name )\Page File Bytes reports the size of the paging file; its value tends to rise during a memory leak.
• Process ( process_name )\Handle Count reports the number of handles that an application opened for objects it creates. Handles are used by programs to identify resources they must access. The value of this counter tends to rise during a memory leak; however, you cannot rule out a leak simply because this counter's value is stable.

Monitor these counters over a period ranging from two hours to a few days. Logging is recommended, both because of the overhead of monitoring multiple instances of the Process counters and because leaks tend to manifest themselves slowly.

Although any leak is serious, memory leaks are of particular concern when they involve the nonpaged pool. Many system services allocate memory from the nonpaged pool because they need to reference it when processing an interrupt and cannot take a page fault at that time. To identify whether or not a leak affects the nonpaged pool, include the following counters in your monitoring:

    Memory \ Pool Nonpaged Bytes

    Memory \ Pool Nonpaged Allocs

    Process(process_name)\ Pool Nonpaged Bytes

5. What are Kernel-mode and User-mode memory leak?

User-mode memory leaks are always located in pageable pool and cause both the Pool Paged Bytes counter and the page file Usage counter to increase steadily over time. Kernel-mode memory leaks usually deplete nonpaged pool, causing the Pool Nonpaged Bytes to counter to increase, although pageable memory can be affected as well. Occasionally these counters may show false positives because an application is caching data.

6. What is Virtual Memory and how it is different from a Paging?

Virtual memory is a memory management technique that is implemented using both hardware and software. It maps memory addresses used by a program, called virtual addresses, into physical addresses in computer memory.

Paging is a memory management scheme by which a computer stores and retrieves data from secondary storage (HDD) for use in the main memory (RAM). In this scheme, the operating system retrieves data from secondary storage in same-size blocks called pages. Paging is an important part of virtual memory implementations in modern operating systems, using secondary storage to let programs exceed the size of available physical memory.

7. What is a Page File?

RAM is a limited resource, whereas, for most practical purposes, virtual memory is unlimited. There can be many processes, and each process has its own 2 GB of private virtual address space. When the memory being used by all the existing processes exceeds the available RAM, the operating system moves pages (4-KB pieces) of one or more virtual address spaces to the computer’s hard disk. This frees that RAM frame for other uses. In Windows systems, these “paged out” pages are stored in one or more files (Pagefile.sys files) in the root of a partition.

8. What is the paged pool and non-paged pool?

The memory manager component of Windows creates the following memory pools that the system uses to allocate memory: nonpaged pool and paged pool. Both memory pools are located in the region of the address space that is reserved for the system and mapped into the virtual address space of each process.

The nonpaged pool consists of virtual memory addresses that are guaranteed to reside in physical memory as long as the corresponding kernel objects are allocated.

The paged pool consists of virtual memory that can be paged in and out of the system. To improve performance, systems with a single processor have three paged pools, and multiprocessor systems have five paged pools.

9. What is a memory dump?

A memory dump is a process in which the contents of memory are displayed and stored in case of an application or system crash. Memory dump helps software developers and system administrators to diagnose, identify, and resolve the problem that led to an application or system failure. After memory dump, the computer is generally unavailable or inaccessible until it’s rebooted. Memory dump can also be caused by a memory leak when the system is out of memory and can no longer continue its operations.

A memory dump is also known as a core dump (UNIX) and a blue screen of death (BSOD) in Windows-based computers.

10. What are the different types of memory dump?

Windows supports various memory dump formats:

          Kernel-mode dumps

• Complete Memory Dump: It contains full physical memory for the target system.
• Kernel Memory Dump: It contains all the memory in use by the kernel at the time of the crash.
• Small Memory Dump: It contains various information such as the stop code, parameters, list of loaded device drivers, etc.

          User-mode memory dumps

• Full User-Mode Dumps: includes the entire memory space of a process
• Minidumps: includes only selected parts of the memory associated with a process.

(64 KB for 32 bit OS and 128 KB for 64 bit OS)

11. How to analyze the BSOD crash dump?

We can use the Windows Debugger (WinDbg.exe) tool or the Kernel Debugger (KD.exe) tool to read small memory dump files. WinDbg.exe and KD.exe are included with the latest version of the Debugging Tools for Windows SDK.

Steps:

• Create and capture the memory dump associated with the BSOD you are trying to troubleshoot.
• Install and configure WinDbg.exe and the Symbols path to the correct Symbols folder.
• Use WinDbg.exe to Debug and analyze the screen dump, and then get to the root cause of the problem.

12. Where to find dump files?

C:\Windows\Minidump\minidump.dmp or <date-and-time>.dmp

13. Where to find the ntlogon.log file?

C:\Windows\debug

14. What are the different remote management tools?

Integrated Lights-Out (iLO) is a remote server management processor embedded on the system boards of HP ProLiant and Blade servers that allows controlling and monitoring of HP servers from a remote location. HP iLO Management is a powerful tool that provides multiple ways to configure, update, monitor, and run servers remotely. The embedded iLO management card has its own network connection and IP address to which server administrators can connect via Domain Name System (DNS)/Dynamic Host Configuration Protocol (DHCP) or through a separate dedicated management network. iLO provides a remote Web-based console, which can be used to administer the server remotely. The iLO port is an Ethernet port, which can be enabled through the ROM-Based Setup Utility (RBSU). The iLO management tool allows a user to perform the following actions on the server remotely:

- Power on and power off the server.

- Restart the server.

- Monitor the server, regardless of the state of the server’s operating system.

- Measure power usage.

- Apply patches, firmware updates, and critical virus updates through virtual media and virtual folders.

- Access system event logs and the HP Integrated Management Log.

Dell Remote Access Controllers (DRAC) and the Integrated Dell Remote Access Controllers come in a different version where a new (i)DRAC version is often linked to a new generation of PowerEdge servers. iDRAC, where the "i" is for integrated as the hardware part is now often integrated on the motherboard of the server. The standard version of iDRAC the software/hardware is piggy-backed onto one of the server's onboard network interfaces using a unique IP address. When the optional "Enterprise" version of iDRAC has been enabled, it is connected to its own "iDRAC" network interface.

The integrated Dell Remote Access Controller (iDRAC) with Lifecycle Controller is embedded management in every Dell PowerEdge™ server. The data it provides helps you deploy, update, monitor, and maintain Dell servers with no need for any additional software to be installed. This means that you get more essential management tasks done faster, your overall server availability increases and your operational expenses diminish. The Dell iDRAC works regardless of the operating system or hypervisor because it’s embedded within each server from the factory.

IBM Remote supervisor adapter (RSA) is the out-of-band management interface card optional on most IBM x86-based server machines under the IBM System x brand. Remote management is independent of the status of the managed server.

Other IBM remote management tools are:

- Blade Center Advanced Management Module (BCAMM)

- Advanced Systems Management Processor (ASMP)

- Integrated Management Module (IMM)

BIOS vs UEFI - What is the Difference

Basic Input-Output System Vs. Unified Extensible Firmware Interface

Introduction:

Basic Input-Output System (BIOS) and Unified Extensible Firmware Interface (UEFI) are two firmware interfaces for computers that work as an interpreter between the operating system and the computer firmware. Both of these interfaces are used at the startup of the computer to initialize the hardware components and start the operating system which is stored on the hard drive.

Role wise both are the same. The older one is now called Legacy BIOS and the newer version is called UEFI.

BIOS:

BIOS works by reading the first sector of the hard drive (MBR) which has the next device’s address to initialize or code to execute. BIOS also selects the boot device that needs to be initialized for starting the operating system. Since BIOS has been in use since the very beginning (since 1975), it still works in 16-bit mode, limiting the amount of code that can be read and executed from the firmware ROM.

UEFI:

UEFI does the same task a little differently. It stores all the information about initialization and startup in a .efi file instead of the firmware. This file is stored on the hard drive inside a special partition called EFI System Partition (ESP). The ESP partition will also contain the boot loader programs for the Operating System installed on the computer. UEFI is meant to completely replace BIOS in the future and bring in many new features and enhancements that can’t be implemented through BIOS.

Some of those features are discussed below:

(1) Breaking out of size limitations:

BIOS uses the Master Boot Record (MBR) to save information about the hard drive data while UEFI uses the GUID partition table (GPT). The major difference between the two is that MBR uses 32-bit entries in its table which limits the total physical partitions to only 4. Each partition can only be a maximum of 2TB in size, while GPT uses 64-bit entries in its table which dramatically extends the support for size possibilities of the hard drive up to Zeta Byte and maximum 128 partitions. (Read more on the difference between MBR and GPT in my next blog article).

(2) Speed and performance:

Since UEFI is platform-independent, it may be able to enhance the boot time and speed of the computer. This is especially the case when you have large hard drives installed on your computer. This enhancement depends upon how UEFI is configured to run. UEFI can perform better while initializing hardware devices. Normally this speed enhancement is a fraction of the total boot time, so you will not see a huge difference in overall boot time. Developers can make use of the UEFI shell environment which can execute a command from other UEFI apps optimizing the performance of the system further.

(3) Security

'Secure boot' is a feature of UEFI that has been implemented in Windows 8 recently. The biggest benefit of UEFI is its security over BIOS. UEFI can allow only authentic drivers and services to load at boot time, making sure that no malware can be loaded at computer startup. Microsoft implemented this feature to counter-piracy issues in Windows, while Mac has been using UEFI for quite some time now. Secure Boot works by requiring a digital signature of boot loaders which should require a digital signature by the Kernel. This process continues until the operating system is completely started. This secure boot feature is also one of the reasons why it is more difficult to install another operating system on a Windows machine.

(4) Backward Compatibility using the Compatibility Support Module (CSM):

For backward compatibility, most of the UEFI implementations on PC-class machines also support booting in legacy BIOS mode from MBR-partitioned disks, through the Compatibility Support Module (CSM) which provides legacy BIOS compatibility. In that scenario, booting is performed in the same way as on legacy BIOS-based systems, by ignoring the partition table and relying on the content of a boot sector.

BIOS booting from MBR-partitioned disks is commonly called BIOS-MBR, regardless of it being performed on UEFI or legacy BIOS-based systems. As a side note, booting legacy BIOS-based systems from GPT disks is also possible, and it is commonly called BIOS-GPT.

Despite the fact MBR partition tables are required to be fully supported within the UEFI specification, some UEFI firmware immediately switches to the BIOS-based CSM booting depending on the type of boot disk's partition table, thus preventing UEFI booting to be performed from EFI System partitions on MBR-partitioned disks. Such a scheme is commonly called UEFI-MBR.

(5) Network boot support:

UEFI specification includes support for booting over the network through the Preboot eXecution Environment (PXE). Underlying network protocols include Internet Protocol (IPv4 and IPv6), User Datagram Protocol (UDP), Dynamic Host Configuration Protocol (DHCP), and Trivial File Transfer Protocol (TFTP).

Also included support for boot images remotely stored on storage area networks (SANs), with Internet Small Computer System Interface (iSCSI) and Fibre Channel over Ethernet (FCoE) as supported protocols for accessing the SANs.

(6) Boot Manager:

The UEFI specification defines a "boot manager", a firmware policy engine that is in charge of loading the operating system loader and all necessary drivers. The boot configuration is controlled by a set of global NVRAM variables, including boot variables that indicate the paths to the loaders.

Operating system loaders are a class of the UEFI applications. As such, they are stored as files on a file system that can be accessed by the firmware, called EFI System partition (ESP). UEFI defines a specific version of FAT, which encompasses FAT32 file systems on ESPs, and FAT16 and FAT12 on removable media. Supported partition table schemes include MBR and GPT, as well as El Torito volumes on optical disks. UEFI does not rely on a boot sector, although ESP provides space for it as part of the backward compatibility. UEFI booting from GPT disks is commonly called UEFI-GPT.

Boot loaders can also be automatically detected by the UEFI firmware, to enable booting from removable devices. Auto-detection relies on a standardized file path to the operating system loader, depending on the actual architecture to boot. Format of the file path is defined as /BOOT/BOOT.EFI, e.g. /efi/BOOT/BOOTX64.EFI



Technical differences between the two: