Thursday, 30 October 2014

Terminal Services and Remote Administration

By Raul Bernardino


The Overview
By using a terminal service, a client can appear to run Windows Server 2003 locally. All the processing power is done by the server. Windows XP and Windows Server 2003 have a feature called “Remote Desktop” which will allow you to connect remotely to the computer and logon as if you are sat at the machine.  Although Windows Server 2003 can be administered remotely by using an MMC or a Web Administration Interface it is still handy and necessary to be able to physically logon to the server to perform specific tasks.

Windows XP and Windows Server 2003 have a feature called “Remote Desktop” which will allow you to connect remotely to the computer and logon as if you are sat at the machine.
Once connected you will see the desktop as it is on the server and you will be able to work as if you were physically located at the machine.
You can disconnect from the session at any time and reconnect to the same session, continuing where you left of.
Using Windows XP’s fast user switching you can easily transfer your desktop to another machine, e.g. to ask for assistance or to show a file on your desktop.
Remote Desktop on Windows Server 2003 will allow two concurrent connections and doesn’t require any special licenses.
Remote desktop can be further extended by enabling terminal services.
By using terminal services, a client can appear to run Windows Server 2003 locally. All the processing power is done by the server.  The server receives keyboard and mouse requests from the clients (terminals) and transmits the display back. Only one copy of Windows Server 2003 is required.
Rather than installing a full version of Windows on every client, a Windows terminal server can be deployed instead.  Clients whose hardware might not be supported by Windows can still take advantage of the Windows Server 2003 features.
Clients can continue to use their old operating system and benefit from the features and applications from Windows Server 2003.  Many different devices can act as terminal clients (called thin clients). E.g. a Windows 3.11 machine can run terminal services client and appear to be running Windows Server 2003.  Although the client terminals can be very low-end machines with no hard-drive and no operating system, the clients will still need client software to run terminal services.  Terminal Services is also a good way to run applications such as Microsoft Office on incompatible clients.  N.B. Once a server is installed with Terminal Services, applications MUST be installed by using Add/Remove Programs from the Control Panel.
Remote Administration

Unlike Remote Desktop, Terminal Services requires licenses. However Terminal Services allows a lot more clients to connect and enables the use of application sharing. Terminal Services can only be enabled on a machine running Windows Server 2003.
Terminal Services Overview
Using Terminal Services, users can log in multiple times to the same server using different sessions. This allows users to perform many tasks at once.  Users can easily cut and paste between applications running locally and applications running on the Terminal Server.
Using Remote Control, two users can use the same terminal session, in other words one user can control and view another user’s session. This can be used to train users or diagnose problems.  Printers that are connected locally to the client will continue to work from a terminal session. Terminal Services and Remote Desktop use the RDP (Remote Desktop Protocol) v5.2.
A terminal session can be disconnected and reconnected at a later time from another client. The session will effectively remain active until logged off or closed by the server.
The logon process is also encrypted and such things as the number of logon attempts can be controlled through security policies. Data transmitted between the client and server can also be encrypted at four different levels (low, compatible, FIPS compliant or high).
User Accounts created locally on the terminal server or in Active Directory can be used with terminal services.
Terminal Services Requirements
The hardware requirements for a Terminal Server depend upon on how many clients will be connecting and what the clients will be doing once connected.  A Terminal Server requires at least the recommended Windows Server 2003 requirements plus an additional 10Mb RAM for each client connecting.  All though not a requirement, using SCSI disk drives can greatly improve performance. You could also use high-performance bus architecture such as EISA or PCI.  Since many clients will be connecting simultaneously, using a high performance network card will help. You could also install two adapters and dedicate one adapter solely to the RDP protocol.  When running Terminal Services, ensure that only 32-bit applications are used.  In order to run 16-bit applications, Windows uses an emulation service called Windows-on-Windows (WOW), which consumes a lot of system resources. Because 16-bit applications will take up more system resources than 32-bit applications it’s better to use solely 32-bit applications. Terminal Services client runs on a variety of machines. They must support VGA and have at least 4MB of memory. Terminal Services client is available to Windows-based terminals and Intel & Alpha based computers running Windows for Workgroups 3.11, 95, 98, NT 3.51, NT 4.0 2000, XP and 2003. There is also third-party support for Macintosh and UNIX-based computers.
Terminal Services Licenses
Terminal Services has its own licensing method. A Terminal Client must have a valid license when connecting to a Terminal Server.  Either a Windows 2003 Terminal Services Client Access License or a Windows Server 2003 license is required as well as a Client Access License (CAL). Windows 2003 machines that are used as clients already have a Terminal Services Client Access License.  You can use Terminal Services for 90 days before you need to install Terminal Services Licensing and activate them.  N.B. Even after 90 days you will still be able to use Remote Desktop and Remote Assistance connections.
Reference list:

TechNet (N:N) How Terminal Services Works [Online]. Available from:  http://technet.microsoft.com/en-us/library/cc755399(v=ws.10).aspx#w2k3tr_ts_how_kqhp(Accessed: 31 October 2014)


Wiki (N:N) Remote Desktop Services [Online]. Available from:http://en.wikipedia.org/wiki/Remote_Desktop_Services (Accessed: 31 October 2014)

Transmission Control Protocol/Internet Protocol (TCP/IP)

By Raul Bernardino


Introduction:
All communication occurs on any type of networks and all involved parties must use a common language. In the Information Technology (IT) networks, this is known as a protocol.  There are many different protocols that are available for computer networks. The most common and widely used being TCP/IP.
TCP/IP is the standard protocol that is being used on the internet whereas allows any network to access the internet and therefore you must use the TCP/IP protocol suite. In other hand an Active Directory required CP/IP. For that reason, TCP/IP is developed and as a default protocol starting from Windows XP and server 2003.
Protocols
This protocols reference is often made to the TCP/IP stack. This consists of layers of mini applications which are performing the discrete job of sorting and filtering the data packets picked up by the Network Information Center (NIC) and then passing the packet on to the next layer for further processing. Eventually a coherent message pops out of the top of the stack into the operating system for the user to read. The reverse is also true i.e. converting of the reply into data packets that can be sent over the network media.
The layers in a TCP/IP stack write headers for network messages as well as decoding them.  Each level in the stack adds a portion to the network packet which its counterpart in the receiving computer will understand.  Strictly speaking, the NIC isn’t part of TCP/IP, but protocols are bound to a particular adapter.
At the receiving computer, the headers are stripped off as they pass up through the TCP/IP stack until only the bare payload is presented to the user.
The DOD Four Layer Model

TCP/IP is often referred to as the TCP/IP protocol suite. TCP/IP is in fact a group of protocols/applications working together to provide network communication. TCP/IP was invented by the US Department of Defense (DOD) to allow machines to communicate over a network. It is a simpler model than the 7 layer OSI model.  The different components of TCP/IP all function at different layers. These layers group the different components into four different categories.
The Application Layer
The application layer contains the applications that use TCP/IP such as Internet Explorer, chrome, safari, Netscape, and Outlook.  The application layer also contains Application Programming Interfaces (API) such as Winsock, which enables applications to use TCP/IP.
The Transport Layer
The transport layer is responsible for the transfer of data on the network.  There are two different transport protocols TCP and UDP. Both protocols provide transport but it works in different ways.
Transmission Control Protocol (TCP)
TCP is a connection-orientated protocol. Both sides (end to end) confirm that the data is being sent and received.
User Datagram Protocol (UDP)
UDP is a connectionless-orientated Protocol. Both computers presume the other side has received the data.  As an example, name resolution uses UDP. If the query fails then a TCP name query is made.
The Internet Layer
To send data the sender must have a method of distinguishing the recipient. This is called an IP address and they take the form of a unique number on the network. The Internet Protocol is responsible for these addresses.  The Internet Control Messaging Protocol (ICMP) is used to test connectivity between machines by sending ICMP messages using the PING command.  The Internet Group Messaging Protocol (IGMP) is used to send data to groups of machines, e.g. Streaming Video. This is known as Multicast.  The Address Resolution Protocol (ARP) is responsible for changing an IP address into the network card’s physical address. Every network card has a unique physical address hardwired into the card itself which is needed for communication on a network.
The Physical Layer
The physical layer is responsible for the actual physical media and how the data is sent to another machine, e.g. Fibre Optic, ATM.  There are many ways to send data down the cable, the most common technologies for LANs are Token Ring and Ethernet. In order for two machines to communicate they must be using the same technology or be connected via a bridge.
Reference list:
Wiki, (n:n) Network Interface Controller, [On-line]. Available from:http://en.wikipedia.org/wiki/Network_interface_controller(Accessed: 20 October 2014)

Identity and Access Management (IAM)

By Raul Bernardino

Introduction:

Identity and Access Management (IAM) is a framework which is consisting of the technical, policy, and governance components or a framework for business processes that facilitates the management of the electronic identities. The framework is including technology and to support management of the identities. This framework can allow an organization to:

·     identify individuals
·     link identities with rolesresponsibilities and affiliations
·     assign privilegesaccess, and entitlements based on identity and associations

This IAM is certifying data stewards and service providers to control access to the information and/or services, according to an individual's identity, roles and responsibilities.

IAM is covered of four main areas as follows:
·     Credential (assignment of an unique token to an entity needing access to resources)
·     Authentication (act of validating proof of identity)
·     Authorization (act of affording access to only appropriate resources and functions)
·     Accountability (ensuring against illegitimate utilization of an entity’s authority…flows from the first 3 functions)

Below is IAM diagram:

Mosaic Integration
The inclination of individual project teams to address integration concerns on a case-by-case basis is natural. The effort involved in many “one-off”, or “point-to-point”, integration scenarios may seem trivial at first, especially when compared to the effort involved in defining and managing an integration infrastructure (after all,

I can set-up that FTP transfer in a couple lines of Perl (or PHP, or whatever)). Only when looking at the “big picture” can we truly appreciate what a tangled mess these “point-to-point” integrations engender. The metadata concerning “what's connecting to what”, the inconsistent security models, and the tight-coupling of service interfaces with implementations, all contribute to the sort of “brittle” environments discussed above.

Developing a coherent integration infrastructure must be a collaborative effort. In order for this collaboration to be productive, recognition and respect of roles, expertise and “spheres of influence” must be maintained. The SIA team recognizes that the technical leads of the various Mosaic Project initiatives will be responsible for identifying integration concerns, application and business-driven technical requirements. These may include, but are not limited to:
·        data consistency and periodicity of synchronization
·        specification of integration points
·        definition of service interfaces/business objects
·        definition of technical capabilities/limitations within the application environment (e.g., the ability to expose a service via SOAP)

The value that the SIA team brings to the Mosaic project lies in the definition of the infrastructural framework, integration patterns, governance and best practices which can be applied to the aforementioned concerns and requirements. The recognition and support of this “domain expertise” on the part of the Mosaic project teams will be paramount in developing and maintaining a “cross-initiative” integration perspective—substantially reducing the likelihood of falling into the traditional traps of point-to-point integration while bolstering the potential for standardization, optimization and reuse of integration resources.

References List:
Rouse M. (n:n:), Identity Management (ID management), [On-line]. Available from: http://searchunifiedcommunications.techtarget.com/definition/identity-management (Accessed: 13 October 2014)
AN. (11-12 April 2011), Requirements for a Global Identity Management Service, [On-line]. Available from:  http://www.w3.org/2001/03/WSWS-popa/paper57 (Accessed: 13 October 2014)