Linux Installation From Usb drive

To find information about your devices and current partitions run:
# dmesg | less
# dmesg | egrep -i 'cd|dvd'
# fdisk -l
Use the first command to identify the USB device name.

Mount CD/DVD ISO or DVD ITSELF

Type the following command to mount Fedora 12 iso image:
# mount Fedora-12-x86_64-netinst.iso -o loop /media/cdrom0/
# DVD=/media/cdrom0
# ls -l $DVD
Sample outputs:

total 6

dr-xr-xr-x 3 root root 2048 2009-11-09 05:37 EFI

drwxr-sr-x 3 root  499 2048 2009-11-09 05:37 images

drwxr-sr-x 2 root  499 2048 2009-11-09 05:36 isolinux

You need to use files stored in isolinux directory to create a bootable usb pen.

Format Usb

Create the fdisk partition:
# fdisk /dev/sdb
You need to create only 1 partition. Next format the partition:
# USB=/media/usb
# mkdosfs /dev/sdb1
Finally mount the partition:
# mkdir -p /media/usb
# mount /dev/sdb1 /media/usb
# USB=/media/usb

Copy Required Files

Type the following commands:
# cp -av $DVD/isolinux/* $USB
# cd $USB
# rm isolinux.bin boot.cat TRANS.TBL
# mv isolinux.cfg syslinux.cfg

Also copy the installer's initial RAM disk $DVD/images/pxeboot/initrd.img (for CentOS / RHEL Linux use $DVD/RedHat/images/pxeboot/initrd.img file) CD/DVD onto the usb drive:
# cp -v $DVD/images/pxeboot/initrd.img $USB

Unmount the USB drive

# umount /dev/sdb1

Make the USB Bootable

Type the following command to make the USB drive bootable
# syslinux /dev/sdb1
# mount /dev/sdb1 $USB
syslinux is a boot loader for the Linux operating system which operates off an MS-DOS/Windows FAT filesystem.

Install Grub

Type the following command to install GRUB on the USB device:
# grub-install --root-directory=$USB /dev/sdb
Create grub.conf:
# cd $USB
# mkdir -p boot/grub
Edit the grub.conf file

default=0

timeout=5

root (hd1,0)

title Fedora Linux

kernel /vmlinuz

initrd /initrd.img

Finally, unmount the USB pen drive, enter:
# umount /dev/sdb1

SSl configration in Server 2008

Installing an SSL Certificate in Windows Server 2008 (IIS 7.0)

Microsoft's new server platform, Windows Server 2008 uses Internet Information Services (IIS) 7.0. This new version makes big changes in the way that SSL certificates are generated, primarily making it much easier than previous versions of IIS. In addition to the new method of requesting and installing SSL certificates, IIS 7 includes the ability to:

• Request more than one SSL certificate at a time
• Import, export, and renew SSL certificates easily in IIS
• Quickly create a self-signed certificate for testing

This article will walk you through the process of ordering an SSL certificate from a commercial certificate authority and installing it on an IIS 7 Windows Server 2008 machine.

Create the Certificate Signing Request

The first step in ordering an SSL certificate is generating a Certificate Signing Request. This is very easy to do in IIS7 using the following instructions. Click here to hide or show the images

1. Click on the Start menu, go to Administrative Tools, and click on Internet Information Services (IIS) Manager.

   

2. Click on the name of the server in the Connections column on the left. Double-click on Server Certificates.

   

3. In the Actions column on the right, click on Create Certificate Request...

   

4. Enter all of the following information about your company and the domain you are securing and then click Next.

   

   Name	Explanation	Examples
   Common Name	The fully qualified domain name (FQDN) of your server. This must match exactly what you type in your web browser or you will receive a name mismatch error.	*.google.com mail.google.com
   Organization	The legal name of your organization. This should not be abbreviated and should include suffixes such as Inc, Corp, or LLC.	Google Inc.
   Organizational Unit	The division of your organization handling the certificate. (Most CAs don't validate this field)	IT Web
   City/Locality	The city where your organization is located.	Mountain View
   State/province	The state/region where your organization is located. This shouldn't be abbreviated.	California
   Country/Region	The two-letter ISO code for the country where your organization is location.	US GB

5. Leave the default Cryptographic Service Provider. Increase the Bit length to 2048 bit or higher. Click Next.

   

6. Click the button with the three dots and enter a location and filename where you want to save the CSR file. Click Finish.

   

Once you have generated a CSR you can use it to order the certificate from a certificate authority. If you don't already have a favorite, you can compare SSL features from each provider using our SSL Wizard or by comparing cheap SSL certificates, Wildcard Certificates, or EV certificates. Once you paste the contents of the CSR and complete the ordering process, your order is validated, and you will receive the SSL certificate file.

Install the Certificate

To install your newly acquired SSL certificate in IIS 7, first copy the file somewhere on the server and then follow these instructions:

1. Click on the Start menu, go to Administrative Tools, and click on Internet Information Services (IIS) Manager.
2. Click on the name of the server in the Connections column on the left. Double-click on Server Certificates.

   

3. In the Actions column on the right, click on Complete Certificate Request...

   

4. Click the button with the three dots and select the server certificate that you received from the certificate authority. If the certificate doesn't have a .cer file extension, select to view all types. Enter any friendly name you want so you can keep track of the certificate on this server. Click OK.

   

5. If successful, you will see your newly installed certificate in the list. If you receive an error stating that the request or private key cannot be found, make sure you are using the correct certificate and that you are installing it to the same server that you generated the CSR on. If you are sure of those two things, you may just need to create a new Certificate Request and reissue/replace the certificate. Contact your certificate authority if you have problems with this.

   

Bind the Certificate to a website

1. In the Connections column on the left, expand the sites folder and click on the website that you want to bind the certificate to. Click on Bindings... in the right column.

   

2. Click on the Add... button.

   

3. Change the Type to https and then select the SSL certificate that you just installed. Click OK.

   

4. You will now see the binding for port 443 listed. Click Close.

   

Install any Intermediate Certificates

Most SSL providers issue server certificates off of an Intermediate certificate so you will need to install this Intermediate certificate to the server as well or your visitors will receive a Certificate Not Trusted Error. You can install each Intermediate certificate (sometimes there is more than one) using these instructions:

1. Download the intermediate certificate to a folder on the server.
2. Double click the certificate to open the certificate details.
3. At the bottom of the General tab, click the Install Certificate button to start the certificate import wizard. Click Next.

   

4. Select Place all certificates in the following store and click Browse.

   

5. Check the Show physical stores checkbox, then expand the Intermediate Certification Authorities folder, select the Local Computer folder beneath it. Click OK. Click Next, then Finish to finish installing the intermediate certificate.

   

You may need to restart IIS so that it starts giving out the new certificate. You can verify that the certificate is installed correctly by visiting the site in your web browser using https instead of http or using our SSL Checker.

active directory Structor

Active Directory Data Store (Directory)

The Active Directory data store is the database that holds all the directory information such as information on users, computer, groups, other objects, and information on the objects which users can access. It also includes other network components. Another name used to refer to the Active Directory data store is the directory. The Active Directory data store or directory is stored on the hard disk of the server by means of the Ntds.dit file. The file has to be stored on a drive that is formatted with the NTFS file system. The Ntds.dit file is placed in the Ntds folder in the systemroot. When changes are made to the directory, these changes are saved to the Ntds.dit file. Because all the data in Active Directory is stored in one distributed data store, the availability of data is improved. A centralized data store means less duplication, and also needs less administration.

Because domain controllers are utilized to manage domains, each domain controller within the domain hosts a write copy of the Active Directory directory. This means is that if one domain controller is unavailable; users, computers and programs would still able to still access the Active Directory data store hosted on a different domain controller in the particular domain. When changes are made to the data store on one domain controller, these changes are replicated to the remainder of the domain controllers within the domain. Because of Active Directory replication, domain controllers in a domain remain synchronized with one another. Active Directory replication occurs automatically. Only domain data, configuration data and schema data is replicated.

Information stored in Active Directory is not all placed in the identical location. The different locations wherein data is stored is called directory partitions. The domain partition holds information about the domain such as users, and resources in the domain. The configuration partition contains information on the Active Directory structure such as the configuration of the domains, domain trees and forests. The schema partition stores information on object classes and attributes.

Active Directory Objects

All information on users, groups, computers, servers and security policies in Active Directory are organized and categorized into different Active Directory objects. An Active Directory object can be defined as a group of attributes that represents a resource in the network. Each object has a unique name or unique identifier called a distinguished name. Objects can also contain other objects. These objects are known as containers. In the Active Directory Users and Computers console, the default object types created in a new domain in Active Directory are:

• Domain, Organizational Unit, User, Computer, Contact, Group, Shared Folder and Shared Printer

Active Directory Components

Domains, organizational units (OUs), domain trees and forests are considered logical structures. Sites and domain controllers are considered physical structures.

• Domains are the main logical structure in Active Directory because they contain Active Directory objects. Network objects such as users, printers, shared resources, and more, are all stored in domains. Domains are also security boundaries. Access to objects in the domain is controlled by access control lists (ACLs). You can use the domain functional level to enable additional Active Directory features. You do this by raising the domain functional level of the domain controllers within the domain. In Windows 2000, the domain mode concept was used and not the domain functional level. The domain functional levels that can be specified are Windows 2000 Mixed, Windows 2000 Native, Windows Server 2003 Interim and Windows Server 2003.
• Organizational Unit (OU): An OU is a container that enables you to organize objects such as users, computers and even other OUs in a domain to form a logical administrative group. An OU is the smallest Active Directory component to which you can delegate administrative authority. A domain can have it own unique OU hierarchy.
• Domain Trees: When you group multiple domains into a hierarchical structure by adding child domains to a parent domain, you are basically forming a domain tree. Domains are regarded as being part of the same domain tree when they have a contiguous naming structure. A two-way transitive trust relationship is automatically created between the parent domain and child domains when you create the child domain.
• Forests: A forest is the grouping of multiple domain trees into a hierarchical structure. Domain trees in a forest have a common schema, configuration, and global catalog. Domains within the forest are linked by two-way transitive trust. Through the forest functional level, you can enable additional forest wide Active Directory features. The forest functional levels that can be set are Windows 2000, Windows Server 2003 Interim, and Windows Server 2003.
• Sites: In Active Directory, sites are formed through the grouping of multiple subnets. Sites are typically defined as locations in which network access is highly reliable, fast and not very expensive.
• Domain Controllers (DCs): A domain controller is a server that stores a write copy of Active Directory. They maintain the Active Directory data store. Certain master roles can be assigned to domain controllers within a domain and forest. Domain controllers that are assigned special master roles are called Operations Masters. These domain controllers host a master copy of particular data in Active Directory. They also copy data to the remainder of the domain controllers. There are five different types of master roles that can be defined for domain controllers. Two types of master roles, forest-wide master roles, are assigned to one domain controller in a forest. The other three master roles, domain-wide master roles, are applied to a domain controller in every domain.
  • The Schema Master is a forest-wide master role applied to a domain controller that manages all changes in the Active Directory schema.
  • The Domain Naming Master is a forest-wide master role applied to a domain controller that manages changes to the forest, such as adding and removing a domain. The domain controller serving this role also manages changes to the domain namespace.
  • The Relative ID (RID) Master is a domain-wide master role applied to a domain controller that creates unique ID numbers for domain controllers and manages the allocation of these numbers.
  • The PDC Emulator is a domain-wide master role applied to a domain controller that operates like a Windows NT primary domain controller. This role is typically necessary when there are computers in your environment running pre-Windows 2000 and XP operating systems.
  • The Infrastructure Master is a domain-wide master role applied to a domain controller that manages changes made to group memberships.

Active Directory Schema

The Active Directory schema defines what types of objects can be stored in Active Directory. It also defines what the attributes of these objects are. The schema is defined by the following two types of schema objects or metadata:

• Schema class objects, also known as schema classes: Define the objects that can be created and stored in Active Directory. The schema attributes store information on the schema class object when you create a new class. A schema class is therefore merely a set of schema attribute objects.
• Schema attribute objects, also known as schema attributes: Schema attributes provide information on object classes. The attributes of an object is also called the object’ properties.

Although Active Directory includes a large number of object classes, you can create additional object classes if necessary. These additions are known as extensions to the schema. Extensions can only be performed on the domain controller acting the Schema Master role.

The object classes that can be used on access control lists (ACLs) to protect security objects are User, Computer, and Group. These object classes are called security principals. A security principal has a Security Identifier (SID) which is a unique number. A security Principal’s SID consists of the security Principal’s domain and a Relative ID (RID). The RID is a unique suffix.

A few other concepts associated with the Active Directory schema are:

• Class Derivations: Set a way for forming new object classes using existing object classes.
• Schema Rules: The Active Directory directory service implements a set of rules into the Active Directory schema that control the manner in which classes and attributes are utilized, and what values classes and attributes can include. Schema rules are organized into Structure Rules, Syntax Rules, and Content Rules
• Structure Rules: The structure rule in Active Directory is that an object class can have only specific classes directly on top of it. These specific classes are called Possible Superiors. Structure rules prevent you from placing an object class in an inappropriate container.
• Syntax Rules: These rules define the types of values and ranges allowed for attributes.
• Content Rules dictate what attributes can be associated with a particular class.

Global Catalog

The global catalog is a central information store on the objects in a forest and domain, and is used to improve performance when searching for objects in Active Directory. The first domain controller installed in a domain is designated as the global catalog server by default. The global catalog server stores a full replica of all objects in its host domain, and a partial replica of objects for the remainder of the domains in the forest. The partial replica contains those objects which are frequently searched for. It is generally recommended to configure a global catalog server for each site in a domain. You can use the Active Directory Sites and Services console to set up additional global catalog servers.

Group Policies and Active Directory

Active Directory enables you to perform policy based administration through Group Policy. Through group policies, you can deploy applications and configure scripts to execute at startup, shutdown, logon, or logoff. You can also implement password security, control certain desktop settings, and redirect folders. When you create new group policies in Active Directory, the policy is stored as Group Policy Objects (GPOs). In Active directory, you can apply a GPO to a domain, site or Organizational Unit.

Active Directory Object Naming Schemes

Each object in the Active Directory data store must have a unique name. Active Directory supports a number of object naming schemes for naming objects:

• Distinguished name (DN): Each object has a DN. The DN uniquely identifies a particular object and uniquely identify where the object is stored. The components that make up the DN of an object are:
  • CN – common name
  • OU – organizational unit
  • DC – domain component
• A canonical name is merely a different manner of depicting the object’s DN in a method that is simpler to interpret.
• Relative distinguished name (RDN): The RDN identifies a particular object within a parent container or OU.
• Globally unique identifier (GUID): A GUID is a unique hexadecimal number that is assigned to an object at the time that the object is created. The GUID of an object never changes.
• User principal name (UPN): The UPN is made up of the user account name of the user, and a domain name that identifies the domain that contains the user account.

Active Directory Replication

In Active Directory, replication ensures that any changes made to a domain controller within a domain are replicated to all the other domain controllers in the domain. Active Directory utilizes multimaster replication to replicate changes in the Active Directory data store to the domain controllers. With multimaster replication, domains are considered peers to one another.

With Windows Server 2003, the Knowledge Consistency Checker (KCC) is used to create a replication topology of the forest, to ensure that the changes are replicated efficiently to the domain controllers. A replication topology reflects the physical connections utilized by domain controllers to replicate the Active Directory directory to domain controllers in a site, or in different sites. Intra-site replication occurs when the Active Directory directory is replicated within a site. When replication occurs between sites, it is known inter-site replication. Since the bandwidth between sites are typically slow, information on site link objects is utilized to identify the most favourable link that should be used for moving replication data between sites in Active Directory.

Active Directory Trust Relationships

In Active Directory, when two domains trust each other or a trust relationship exists between the domains, the users and computers in one domain can access resources residing in the other domain. The trust relationships supported in Windows Server 2003 are summarized below:

• Parent/Child trust: A parent/child trust relationship exists between two domains in Active Directory that have a common contiguous DNS namespace, and who belong to the identical forest. This trust relationship is established when a child domain is created in a domain tree.
• Tree Root trust: A tree root trust relationship can be configured between root domains in the same forest. The root domains do not have a common DNS namespace. This trust relationship is established when a new tree root domain is added to a forest.
• Shortcut trust: This trust relationship can be configured between two domains in different domain trees but within the same forest. Shortcut trust is typically utilized to improve user logon times.
• External trust: External trust relationships are created between an Active Directory domain and a Windows NT4 domain.
• Realm trust: A realm trust relationship exists between an Active Directory domain and a non-Windows Kerberos realm.
• Forest trust: Forest trust can be created between two Active Directory forests.

UnderStanding Trust Relationship

What are trust relationships

In the Windows NT domain model, domains had to be bound together through trust relationships, simply because the SAM databases used in those domains could not be joined. What this meant was that where a domain trusted another Windows NT domain, the members of the domain could access network resources located in the other domain. Defining trust relationships between domains eliminates the need for an Administrator to configure user accounts in multiple domains.

In a trust relationship, the two domains are referred to as the trusting domain and the trusted domain. The trusted domain is the domain where the trust relationship is created. The trusting domain is the other domain specified in the trust, that is, the one wherein network resources can to be accessed. The trusting domain in this case recognizes the logon authentications of the trusted domain. The logon trust relationship is supported by the NT LanMan Challenge Response. This allows pass-through authentication of users from the trusted domain. One of the shortfalls of Windows NT trust relationships is that trusts between domains were one-way and nontransitive. This meant that the defined trust relationship ended with the two domains between which the particular trust was created. The rights implicit in the trust relationship also flowed only in one single direction. Because of this, defining and managing trust relationships in the Windows NT domain structure was a cumbersome and labour intensive task. The Windows NT domain worked well in small enterprises where one domain typically existed in the enterprise. In those larger enterprises that have multiple domains, Administrators have to define trust relationships between the domains in order for a user in one domain to access resources in another domain.

In Windows 2000 and Windows 2003, Active Directory is built on the concept of trust relationships between domains. Although the actual concept of trust relationships is not new in Windows Server 2003, there are new trust capabilities and trust types available for Windows Server 2003 Active Directory domains.

In Windows Server 2003, authentication of users or applications occurs through the use of one of the following trust protocols:

• NT LAN Manager (NTLM) protocol: This protocol is used when one of the computers in the trust relationship does not support the Kerberos version 5 protocol.

• The Kerberos version 5 protocol is the default trust protocol used when computers in trust relationships are running Windows Server 2003.

The characteristics of Windows Server 2003 trusts are outlined below:

• Trusts can be nontransitive or transitive:

  • Transitive trusts: With transitive trusts, trust is applicable for each trusted domain. What this means is where Domain1 trusts Domain2, and Domain2 trusts Domain3; Domain1 would also trust Domain3.

  • Nontransitive trust: The defined trust relationship ends with the two domains between which the particular trust is created.

• Trusts can be one-way or two-way trusts:

  • One-way trusts: Based on the direction of the trust, one-way trust can further be broken into either incoming trust or outgoing trusts. One way trust can be transitive or nontransitive:

    • Incoming Trust: With incoming trust, the trust is created in the trusted domain, and users in the trusted domain are able to access network resources in the trusting domain or other domain. Users in the other domain cannot however access network resources in the trusted domain.

    • Outgoing Trust: In this case, users in the other domain able to access network resources in the initiating domain. Users in the initiating domain are not able to access any resources in the other domain.

  • Two-way trusts: A two-way trust relationship means that where Domain1 trusts Domain2, then Domain2 trusts Domain1. The trust basically works both ways, and users in each domain are able to access network resources in eitherone of the dolmans. A two-way, transitive trust relationship is the trust that exists between parent domains and child domains in a domain tree. In two-way transitive trust, where Domain1 trusts Domain2 and Domain2 trusts Domain3, then Domain1 would trust Domain3 and Domain3 would trust Domain1.Two-way, transitive trust is the default trust relationship between domains in a tree. It is automatically created and exists between top-level domains in a forest.

• Trusts can be implicit or explicit trusts:

  • Implicit: Automatically created trust relationships are called implicit trust. An example of implicit trust is the two-way, transitive trust relationship that Active Directory creates between a parent and child domains.

  • Explicit: Manually created trust relationships are referred to as explicit trust.

Window Server 2003 Active Directory Forest Trust Capability

Forest trust is a new feature introduced with Windows Server 2003 Active Directory. To better understand the feature, lets first look at how forest trust was established in the Windows NT and Windows 2000 domain structures. In these domain structures, when users located in one forest needed to access resources located in a different forest, an external trust relationship had to be defined between the two domains. External trusts are one-way and nontransitive in nature. This in turn increases the Administrative effort required to create and maintain the external trusts needed to enable forest trust in the Windows NT and Windows 2000 domain structures. Forest trust on the other hand enables you to create two-way trust relationships between all domains in two forests. The number of external trusts that has to be configured in Windows NT and Windows 2000 domain structures is reduced in Windows Server 2003 Active Directory domains. The trust between the Active Directory forests is transitive in nature.

Types of Active Directory Trust Relationships

The types of trust relationships that can be created and configured for Active Directory domains are discussed in this section. As an Administrator for Active Directory Windows Server 2003 domains, it is important to understand the different types of trust that are supported in Windows Server 2003, and to know which trust relationship to create for the different network resource access requirements that exist within your organization.

• Tree-root trust: Tree-root trust is automatically/implicitly created when a new tree root domain is added to a forest. The trust relationship exists between two root domains within the same forest. For instance, if you have an existing forest root domain, and you add a new tree root domain to the same forest, tree-root trust is formed between the new tree root domain and the existing forest root domain. Tree-root trust is transitive and two-way.

• Parent-child trust: Parent-child trust is implicitly established when new child domains are added to a domain tree. Parent-child trust is a two-way, transitive trust relationship. Active Directory automatically creates a trust relationship between the new child domain, and the domain directly above it in the domain namespace hierarchy. What this means is that the trust relationship exists between those domains that have a common contiguous DNS namespace and who are part of the same forest. Parent-child trust enables authentication requests of child domains to be passed through the parent domain for authentication. In addition, when a new domain is added to the tree, trust relationships are created with each domain in the tree. This means that network resources in the individual domains of the tree can be accessed by all other domains in the tree.

• Shortcut trust: Shortcut trust is explicitly created by an Administrator, and can defined to be either one-way transitive trust, or two-way transitive trust. Shortcut trust is usually created when you want to speed up, or enhance authentiction performance between two domains in different trees but within the same forest. One-way shortcut trust should be created when users in Domain1 need to access Active Directory objects in Domain2 but users in Domain2 do not need to access objects in Domain1. Two-way shortcut trust should be created when users in each domain need to access objects in each other domain.

• Realm trust: Realm trust is explicitly created by an Administrator, and can be defined as either transitive trust or nontransitive trust, and can also either be one-way trust or two-way trust. Realm trust enables you to create a trust relationship between a Windows Server 2003 Active Directory domain and a non-Windows Kerberos version 5 realm. Realm trust therefore facilitates interoperability between a Windows Server 2003 domain and a realm used in Kerberos version 5 implementations.

• External trust: External trust is explicitly defined by an Administrator to enable trust between domains that are located in different forests, and to create trust between an Active Directory domain and a down-level Windows NT 4 domain. External trust is always nontransitive but can be either one-way trusts or two-way trusts. External trust is usually only created in Windows Server 2003 Active Directory environments when users need to access network resources in a domain that resides in a different forest, and forest trust cannot be created between the two domains. When external trust is created between an Active Directory domain and a down-level Windows NT 4 domain, it is a one-way, nontransitive trust relationship.

• Forest trust: Forest trust is explicitly created by an Administrator to enable trust between two Active Directory forests. Forest trust is transitive in nature, and can either be one-way or two-way. Forest trust is only available in Windows Server 2003. Before you can create forest trust between two forests, each domain in the particular forests, and each forest, has to be raised to, and running at the Windows Server 2003 functional level. Because forest trust is created between two root domains of two forests, it can create two-way trusts with each domain within the two forests. This basically means that users would be able to access Active Directory objects between all domains encompassed by the particular forest trust relationship.

Planning Considerations for Trust Relationships

Tree-root trust and Parent-child trust is implicitly created by Active Directory when new domains are created. What this means is that you do not need to explicitly create these trusts, nor do you have to perform any configuration or management tasks for the trust relationships.

Shortcut trust, Realm trust, External trust and Forest trust differ to Tree-root and Parent-child trust, in that the former four trusts have to be explicitly created and managed. Because of the different types of trust relationships that can be created, you need to plan which type of trust relationship to create for the domains within your Active Directory environment.

Shortcut Trust

Before you can create any shortcut trusts, you must be a member of the Enterprise Admin or Domain Admin groups in each domain in the forest. Another requirement is that the domains you are creating shortcut trust for, are Windows Server 2003 domains that reside in the same forest. As mentioned earlier, Shortcut trust is usually created to speed up authentication between two domains in different trees but within the same forest. Shortcut trust can be one-way transitive trust, or two-way transitive trust. What shortcut trust essentially does is it shortens the trust path traversed for authentication requests made between domains of different trees. Shortcut trust is typically configured in an intricate forest where users continually need to access resources of domains belonging to different trees. Shortcut trust improves query response performance as well.

• You would need to create one-way shortcut trust when the optimized tust path is only needed for one of the domains in the trust. The other domain's users would need to transverse the full trust path when handling authentication requests.

• You would need to create two-way shortcut trust when the users in each domain need to use the shortened trust path for authentication requests.

The Active Directory tool that you use to create shortcut trust is the Active Directory Domains and Trusts console. The console enables you to specify selective authentication for incoming shortcut trust and outgoing shortcut trust. What this means is that you can set authentication differently for the two forms of trust. When you set selective authentication for incoming shortcut trust, you would need to specify permissions for every resource that users in the other domain should be able to access. If domain wide authentication is specified on the incoming shortcut trust, users in the other domain and users in the local domain have the identical permissions to network resources.

Realm Trust

In order to create realm trust, you should have Enterprise Admin or Domain Admin permissions for the Windows Server 2003 domain, and you should have the permissions required for the non-Windows Kerberos version 5 realm. You would typically create realm trust to enable trust between a Windows Server 2003 domain and a MIT or Unix v5 Kerberos realm. You can create Realm trust as either transitive or nontransitive trust, and as either be one-way trust or two-way.

External Trust

You need to be a member of Enterprise Admins or Domain Admins of the Windows Server 2003 domain and you need to be a member Enterprise Admins or Domain Admins of the other domain, to create one-way External trust or two-way External trust.

Recall from an earlier discussion, that External trust is always nontransitive in nature, and is typically used to enable trust between an Active Directory domain and a down-level Windows NT 4 domain. When the External trust is created, security principals (Users, Groups, Computers) from the external domain are able to access network resources in the internal domain (Windows Server 2003 domain). The foreign security principals can be examined in the Active Directory Users And Computers console. The only requirement is that Advanced Features are enabled. You can explicitly define different authentication for incoming External trusts and outgoing External trusts.

Forest Trust

You need to belong to the Enterprise Admins groups in each forest that you want to create forest trust between. In addition to this, the domains within each forest and each particular forest have to be raised to the Windows Server 2003 functional level.

Forest trust is typically created when enterprises merge or takeovers occur, and each company within the enterprise still needs to maintain some form of administrative independence. This trust relationship enables users to access Active Directory objects between all domains impacted by the particular forest trust relationship. Forest trust is transitive, and can be one-way or two-way trust. You would create one-way Forest trusts when users in the trusted forest need to access Active Directory objects in the trusting forest, but those users in the trusting forest do not need to access resources in the trusted forest. You would create two-way Forest trust in cases where users in either one of the forests need to access resources hosted in the other forest.

How to create Shortcut trust using Active Directory Domains and Trusts

1. Open the Active Directory Domains and Trusts console.

2. In the console tree, locate and right-click the domain for which you want to configure Shortcut trust, and click Properties from the shortcut menu.

3. When the Properties dialog box of the domain you chose opens, click the Trusts tab

4. Click the New Trust button at the bottom of the dialog box.

5. This action starts the New Trust Wizard.

6. Click Next on the Welcome To The New Trust Wizad page.

7. When the Trust Name page opens, enter the DNS name of the other domain that you want to create trust with. Click Next.

8. On the Direction Of Trust page, you can select one of the following options:

   • Two-Way: Click this option if you want to define two-way Shortcut trust. This would mean that users in each domain would be able to access resources in both domains.

   • One-Way: Incoming: This option should be enabled if you only want users of this particular domain to be able to access resources in the other domain.

   • One-Way: Outgoing: This option should be selected if you want users of the other domain to be able to access resources in this particular domain.

   Click Next.

9. When the Sides Of Trust page opens, you can select one of these options:

   • This Domain Only: Selecting this option creates the Shortcut trust in the local domain.

   • " Both This Domain And The Specified Domain: Selecting this option creates the Shortcut trust in the local domain and in the other domain that you indicated.

   Click Next

10. The New Trust Wizard displays different pages next, based on what you have selected in the previous two steps.

11. Where Two-Way or One-Way: Outgoing was selected in Step 8, and This Domain Only was selected in Step 9, the wizard displays the Outgoing Trust Authentication Level page. You can select either Domain Wide Authentication or Selective Authentication. Choosing Domain Wide Authentication results in the automatic authentication of users in the other domain for network resources in the local domain. If you select Selective Authentication, the users in the other domain are not automatically authenticated for resources in the local domain. Click Next. The wizard then displays the Trust Password page. This is where you have to set the password for the trust. Click Next.

12. Where One-Way: Incoming was selected in Step 8, and This Domain Only was selected in Step 9, the wizard displays the Trust Password page. Enter the password for the trust in the boxes. Click Next.

13. Where Both This Domain And The Specified Domain was selected in Step 9, the wizard displays the User Name And Password page. You have to provide the user name and password of an Administrator account that has the necessary rights in the other domain. Click Next.

14. The Trust Selections Complete page is displayed next. All the settings that you previously specified are shown on this page. After checking that the configuration settings are correct, click Next.

15. The New Trust Wizard now creates the shortcut trust relationship.

16. When the Trust Creation Complete page appears, click Next.

17. The Confirm Outgoing Trust page allows you to verify outgoing trust. Click Yes, Confirm The Outgoing Trust or click No, Do Not Confirm The Outgoing Trust. Click Next.

18. The Confirm Incoming Trust page allows you to verify incoming trust. Click Yes, Confirm The Incoming Trust or click No, Do Not Confirm The Incoming Trust. Click Next.

19. Click Finish when the Completing The New Trust Wizard page is displayed.

How to create Realm trust using Active Directory Domains and Trusts

1. Open the Active Directory Domains and Trusts console.

2. In the console tree, locate and right-click the domain for which you want to configure Realm trust, and click Properties from the shortcut menu.

3. When the Properties dialog box of the domain opens, click the Trusts tab

4. Click the New Trust button at the bottom of the dialog box.

5. Click Next on the Welcome To The New Trust Wizard page.

6. When the Trust Name page opens, enter the DNS name of the other domain for the realm trust. Click Next.

7. The Trust Type page appears next. Select Realm Trust. Click Next.

8. When the Transitivity Of Trust page opens, select one of the following options:

   • Nontransitive: Select this option if the Realm trust should end with the two domains betwen which it is created.

   • Transitive: Select this option if you want this particular domain and all other trusted domains to create trust with the realm and other trusted realms.

   Click Next

9. On the Direction Of Trust page, you can select one of the following options:

   • Two-Way: Click this option if you want to define two-way Realm trust. This would mean that users in the domain and realm would be able to access resources in both the domain and realm.

   • One-Way: Incoming: This option should be enabled if you only want users of this particular domain to be able to access resources in the realm.

   • One-Way: Outgoing: This option should be selected if you only want users of realm to be able to access resources in this particular domain.

   Click Next

10. The wizard displays the Trust Password page next. Enter the password for the trust in the boxes. Click Next.

11. The Trust Selections Complete page is displayed next. All the settings that you previously specified are shown on this page. After checking that the configuration settings are correct, click Next.

12. The New Trust Wizard creates the Realm trust relationship.

13. Click Finish on the Completing The New Trust Wizard page.

How to create External trust using Active Directory Domains and Trusts

You first have to specify a DNS forwarder for each of the DNS servers that are authoritative for the trusting forests.

You use the DNS Administration tool to configure DNS forwarders,

1. Click Start, click Administrative Tools, and click DNS.

2. Right-click the DNS server, and click Properties from the shortcut menu.

3. When Properties dialog box of the DNS server opens, click the Forwarders tab.

4. Click New, and enter the DNS domain name that needs queries to be forwarded.

5. In the Selected Domain's IP Address List, enter the IP addresses of the servers to which these queries are forwarded.

6. Click Add

7. Click OK

8. Open the Active Directory Domains and Trusts console.

9. In the console tree, locate and right-click the domain in the initial forest which you want to configure External trust, and click Properties from the shortcut menu.

10. When the Properties dialog box of the domain opens, click the Trusts tab

11. Click the New Trust button at the bottom of the dialog box.

12. Click Next on the Welcome To The New Trust Wizard page.

13. When the Trust Name page opens, enter the DNS name of the domain in the other forest. Click Next.

14. The Trust Type page appears next if the forest functional level is raised to Windows Server 2003 forest functional level. Select the External Trust option. Click Next.

15. The Direction Of Trust page is displayed straight after the Trust Name page if the forest functional level is not raised to Windows Server 2003. You can select one of the following options:

    • Two-Way: Click this option if you want to define two-way External trust. This would mean that users in each domain would be able to access resources in both domains.

    • One-Way: Incoming: This option should be enabled if you only want users of this particular domain to be able to access resources in the other domain.

    • One-Way: Outgoing: This option should be selected if you only want users of the other domain to be able to access resources in this particular domain.

    Click Next

16. When the Sides Of Trust opens, you can select one of these options:

    • This Domain Only: Selecting this option creates the trust in the local domain

    • Both This Domain And The Specified Domain: Selecting this option creates the trust in the local domain and in the other domain.

    Click Next

17. The New Trust Wizard displays different pages next, based on what you selected in the previous two steps.

18. Where Two-Way or One-Way: Outgoing was selected in Step 8, and This Domain Only was selected in Step 9, the wizad displays the Outgoing Trust Authentication Level page. You can select either Domain Wide Authentication or Selective Authentication. Choosing Domain Wide Authentication results in the automatic authentication of users in the other domain for network resources in the local domain. If you select Selective Authentication, the users in the other domain are not automatically authenticated for resources in the local domain. Click Next. The wizard then displays the Trust Password page. This is where you have to set the password for the trust. Click Next.

19. Where One-Way: Incoming was selected in Step 8, and This Domain Only was selected in Step 9, the wizard displays the Trust Password page. Enter the password for the trust. Click Next.

20. Where Both This Domain And The Specified Domain was selected in Step 9, the wizard displays the User Name And Password page. You have to provide the user name and password of an Administrator account that has the necessary rights. Click Next.

21. When the Trust Selections Complete page is displayed, the settings that you previously specified are shown. After checking that the configuration settings are correct, click Next.

22. The New Trust Wizard now creates the External trust.

23. When the Trust Creation Complete page appears, click Next.

24. The Confirm Outgoing Trust page allows you to verify outgoing trust. Click Yes, Confirm The Outgoing Trust or click No, Do Not Confirm The Outgoing Trust. Click Next.

25. The Confirm Incoming Trust page allows you to verify incoming trust. Click Yes, Confirm The Incoming Trust or click No, Do Not Confirm The Incoming Trust. Click Next.

26. Click Finish.

How to create Forest trust using Active Directory Domains and Trusts

You first have to specify a DNS forwarder for each of the DNS servers that are authoritative for the trusting forests before you can use the Active Directory Domains and Trusts console to create Forest trust relationships. Use the DNS Administration Tool to configure the necessary DNS forwarder. In addition to this, ensure that the forest functional level for each forest is set to Windows Server 2003 forest functional level.

1. Open the Active Directory Domains and Trusts console.

2. In the console tree, locate and right-click the domain in the initial forest which you want to configure Forest trust for, and click Properties from the shortcut menu.

3. When the Properties dialog box of the domain opens, click the Trusts tab and then click the New Trust button.

4. In the Welcome To The New Trust Wizard page, click Next

5. Enter the DNS name of the domain in the other forest on the Trust Name page. Click Next.

6. In the Trust Type page, select the Forest Trust option. Click Next.

7. On the Direction Of Trust page select one of the following options:

   • Two-Way: Click this option if you want to define two-way Forest trust. This would mean that users in each forest would be able to access resources in both forests.

   • One-Way: Incoming: This option should be enabled if you only want users of this particular forest to be able to access resources in the other forest.

   • One-Way: Outgoing: This option should be selected if you only want users of the other forest to be able to access resources in this particular forest.

   Click Next

8. When the Sides Of Trust opens, you can select one of these options:

   • This Domain Only: Selecting this option creates the trust in the local forest.

   • Both This Domain And The Specified Domain: Selecting this option creates the trust in the local forest and in the other forest.

   Click Next

9. Where Two-Way or One-Way: Outgoing was selected in Step 7, and This Domain Only was selected in Step 8, the wizard displays the Outgoing Trust Authentication Level page. You can select either Domain Wide Authentication or Selective Authentication. Choosing Domain Wide Authentication results in the automatic authenticationof users in the other forest for network resources in the local forest. If you specify Selective Authentication, the users in the other forest are not automatically authenticated for resources in the local forest. Click Next. The wizard then displays the Trust Password page. This is where you have to set the password for the trust. Click Next.

10. Where One-Way: Incoming was selected in Step 7, and This Domain Only was selected in Step 8, the wizard displays the Trust Password page. Enter the password for the trust. Click Next.

11. Where Both This Domain And The Specified Domain was selected in Step 8, the wizard displays the User Name And Password page. You have to provide the user name and password of an Administrator account that has the necessary rights. Click Next.

12. When the Trust Selections Complete page is displayed, the settings that you previously specified are shown. After checking that the configuration settings are correct, click Next.

13. The New Trust Wizard now creates the Forest trust.

14. When the Trust Creation Complete page appears, click Next.

15. The Confirm Outgoing Trust page allows you to verify outgoing trust. Click Yes, Confirm The Outgoing Trust or click No, Do Not Confirm The Outgoing Trust. Click Next.

16. The Confirm Incoming Trust page allows you to verify incoming trust. Click Yes, Confirm The Incoming Trust or click No, Do Not Confirm The Incoming Trust. Click Next.

17. Click Finish on the Completing The New Trust Wizard page.

How to remove existing Active Directory trust relationships

1. pen the Active Directory Domains And Trusts console.

2. In the console tree, right-click a domain that is specified in the trust relationship which you want to remove, and select Properties from the shortcut menu.

3. Click the Trusts tab.

4. Use the Domains Trusted By This Domain (Outgoing Trusts) box to select the trust you want to remove.

5. Click the Remove button alongside the box.

6. If you want to remove the trust from the local domain only, click the No, Remove The Trust From The Local Domain Only option, and click OK

7. If you want to remove the trust from the local domain and the other domain, click the Yes, Remove The Trust From Both The Local Domain And The Other Domain option. Enter the appropriate user name and password combination in the User Name and Password boxes and click OK.

8. Click Yes to verify that you want to remove the trust relationship.

9. Use the Domains That Trust This Domain (Incoming Trusts) box to select the trust you want to remove.

10. Choose the appropriate option in the Active Directory dialog box, and then click OK

11. Click Yes to verify that you want to remove the trust relationship.

How to validate existing Active Directory trust relationships

1. Open the Active Directory Domains And Trusts console

2. In the console tree, right-click a domain that is defined in the trust relationship which you want to validate, and select Properties from the shortcut menu.

3. Click the Trusts tab

4. You can select the trust you want to examine in one of the following boxes:

   • Domains Trusted By This Domain (Outgoing Trusts) box

   • Domains That Trust This Domain (Incoming Trusts) box

5. After you have selected the trust, click the Properties button.

6. When the Properties dialog box of the trust opens, click the Validate button.

7. If you only want to verify outgoing trust, click the No, Do Not Validate The Incoming Trust option and click OK.

8. If you want to verify incoming trust and outgoing trust, click Yes, Validate The Incoming Trust option. Enter the appropriate user name and password combination in the User Name and Password boxes and click OK

9. After the trust is validated, a message is displayed indicating this.

10. Click OK

How to create and manage trust relationships using the Windows Domain Manager Command-lineTool

You can use the Windows Domain Manager command line tool to create and manage Active Directory trusts. Netdom.exe is included with the Windows Support Tools available on the Windows Server 2003 Setup CD-ROM.

The netdom trust command is used to create and manage trusts:

netdom trust TrustingDomainName /d: TrustedDomainName [/ud:[Domain]User]

[/pd:{Password|*}] [/uo: User] [/po:{Password|*}] [/verify] [/reset] [/passwordt: NewRealmTrustPassword]

[/add [/realm]] [/remove [/force]] [/twoway] [/kerberos] [/transitive[:{YES|NO}]] [/verbose]

• TrustingDomainName, indicates the name of the trusting domain

• /d: TrustedDomainName, indicates the name of the trusted domain. If this parameter is not specified, the domain to which this computer is a member of is utilized.

• /ud:[Domain]User, indicates the user account that should be used. If this parameter is not specified, the current user account is used.

• /pd:{Password|*}, indicates the password associated with the user account.

• /verify, verifies the trust password for a particular trust

• /reset, resets the trust password for trusted domains

• /passwordt: NewRealmTrustPassword, defines the trust password for the Windows domain if a non-Windows Kerberos realm is defined.

• /add, indicates that a trust relationship should be created

• /realm, defines the trust as being created with a non-Windows Kerberos realm

• /remove, indicates that the trust relationship should be removed

• /force, indicates that the trusted domain object as well as the cross-reference object for the other domain, should be removed.

• /twoway, indicates that two-way trust should be created.

• /kerberos, indicates that the trust protocol should be the Kerberos protocol.

• /transitive[:{YES|NO}], indicates whether trust should be created as transitive or nontransitive trust.

• /verbose, indicates verbose output should be displayed.

Centralized syslog server

This article will explain installing and configuring a syslog log server in redhat enterprise linux. It'll work in other redhat distributions like centos, fedora etc.

Centralized log server (syslog server)

Suppose we have a server and 10 client machines. And we want to monitor the logs of all those client machines. In situations like this, we will use centralized server as a log server. Whatever events are happening in client machines, the logs will be sent to the server. So that we can monitor all the logs from a centralized server. We make use of syslog service for this.

Configuration of server machine(syslog server)

Service name: syslog

configuration file: /etc/sysconfig/syslog

Steps:

1. Open the /etc/sysconfig/syslog file and add "-r" option to the variable SYSLOGD_OPTIONS as shown below.

[root@server ~]# cat /etc/sysconfig/syslog

# Options to syslogd

# -m 0 disables 'MARK' messages.

# -r enables logging from remote machines

# -x disables DNS lookups on messages recieved with -r

# See syslogd(8) for more details

SYSLOGD_OPTIONS="-r -m 0"

# Options to klogd

# -2 prints all kernel oops messages twice; once for klogd to decode, and

# once for processing with 'ksymoops'

# -x disables all klogd processing of oops messages entirely

# See klogd(8) for more details

KLOGD_OPTIONS="-x"

#

SYSLOG_UMASK=077

# set this to a umask value to use for all log files as in umask(1).

# By default, all permissions are removed for "group" and "other".

[root@server ~]#

2. Restart the syslog service.

[root@server ~]# service syslog restart

Shutting down kernel logger: [ OK ]

Shutting down system logger: [ OK ]

Starting system logger: [ OK ]

Starting kernel logger: [ OK ]

[root@server ~]#

Configuration for client machines

service name: syslog

Configuration file: /etc/syslog.conf

Steps:

1. Open the configuration file /etc/syslog.conf and add an entry to redirect the logs to the remote server.

[root@vm1 ~]# cat /etc/syslog.conf

# Log all kernel messages to the console.

# Logging much else clutters up the screen.

#kern.* /dev/console

*.* @192.168.0.19

# Log anything (except mail) of level info or higher.

# Don't log private authentication messages!

*.info;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.

##authpriv.* /var/log/secure

# Log all the mail messages in one place.

mail.* -/var/log/maillog

# Log cron stuff

cron.* /var/log/cron

# Everybody gets emergency messages

*.emerg *

# Save news errors of level crit and higher in a special file.

uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log

local7.* /var/log/boot.log

[root@vm1 ~]#

2. Restart the service

[root@vm1 ~]# service syslog restart

Shutting down kernel logger: [ OK ]

Shutting down system logger: [ OK ]

Starting system logger: [ OK ]

Starting kernel logger: [ OK ]

[root@vm1 ~]#

Checking:

In server open a terminal and watch /var/log/messages and restart syslog service in client. You can see the log from clinet coming to server.

[root@server ~]# tail -f /var/log/messages

Oct 15 14:42:30 vm1 kernel: Kernel logging (proc) stopped.

Oct 15 14:42:30 vm1 kernel: Kernel log daemon terminating.

Oct 15 14:42:31 vm1 exiting on signal 15

Oct 15 14:42:31 vm1 syslogd 1.4.1: restart.

Oct 15 14:42:31 vm1 kernel: klogd 1.4.1, log source = /proc/kmsg started.

Fields in log from remote machine:

Date Hostname Name_of_the_application: Actual_log_message

DNS CONFIGURATION IN RHEL 6

LINUX RHEL 6 BIND DNS 


[root@desktop6 ~]# yum install bind*

Loaded plugins: refresh-packagekit, rhnplugin

This system is not registered with RHN.

RHN support will be disabled.

Setting up Install Process

Package 32:bind-libs-9.7.0-5.P2.el6.x86_64 already installed and latest version

Package 32:bind-utils-9.7.0-5.P2.el6.x86_64 already installed and latest version

Resolving Dependencies

--> Running transaction check

---> Package bind.x86_64 32:9.7.0-5.P2.el6 set to be updated

---> Package bind-chroot.x86_64 32:9.7.0-5.P2.el6 set to be updated

---> Package bind-devel.x86_64 32:9.7.0-5.P2.el6 set to be updated

---> Package bind-dyndb-ldap.x86_64 0:0.1.0-0.9.b.el6 set to be updated

---> Package bind-sdb.x86_64 32:9.7.0-5.P2.el6 set to be updated

--> Processing Dependency: libpq.so.5()(64bit) for package: 32:bind-sdb-9.7.0-5.P2.el6.x86_64

--> Running transaction check

---> Package postgresql-libs.x86_64 0:8.4.4-2.el6 set to be updated

--> Finished Dependency Resolution



Dependencies Resolved



================================================================================

Package              Arch        Version                   Repository     Size

================================================================================

Installing:

bind                 x86_64      32:9.7.0-5.P2.el6         base          3.5 M

bind-chroot          x86_64      32:9.7.0-5.P2.el6         base           65 k

bind-devel           x86_64      32:9.7.0-5.P2.el6         optional      362 k

bind-dyndb-ldap      x86_64      0.1.0-0.9.b.el6           base           47 k

bind-sdb             x86_64      32:9.7.0-5.P2.el6         optional      276 k

Installing for dependencies:

postgresql-libs      x86_64      8.4.4-2.el6               base          188 k



Transaction Summary

================================================================================

Install       6 Package(s)

Upgrade       0 Package(s)



Total download size: 4.4 M

Installed size: 8.9 M

Is this ok [y/N]: y

Downloading Packages:

(1/6): bind-9.7.0-5.P2.el6.x86_64.rpm                    | 3.5 MB     00:00    

(2/6): bind-chroot-9.7.0-5.P2.el6.x86_64.rpm             |  65 kB     00:00    

(3/6): bind-devel-9.7.0-5.P2.el6.x86_64.rpm              | 362 kB     00:00    

(4/6): bind-dyndb-ldap-0.1.0-0.9.b.el6.x86_64.rpm        |  47 kB     00:00    

(5/6): bind-sdb-9.7.0-5.P2.el6.x86_64.rpm                | 276 kB     00:00    

(6/6): postgresql-libs-8.4.4-2.el6.x86_64.rpm            | 188 kB     00:00    

--------------------------------------------------------------------------------

Total                                            31 MB/s | 4.4 MB     00:00    

warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY

base/gpgkey                                              | 6.3 kB     00:00 ...

Importing GPG key 0xFD431D51 "Red Hat, Inc. (release key 2) " from /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

Is this ok [y/N]: y

Importing GPG key 0x2FA658E0 "Red Hat, Inc. (auxiliary key) " from /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

Is this ok [y/N]: y

Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

Warning: RPMDB altered outside of yum.

 Installing     : 32:bind-9.7.0-5.P2.el6.x86_64                            1/6

 Installing     : postgresql-libs-8.4.4-2.el6.x86_64                       2/6

 Installing     : 32:bind-sdb-9.7.0-5.P2.el6.x86_64                        3/6

 Installing     : bind-dyndb-ldap-0.1.0-0.9.b.el6.x86_64                   4/6

 Installing     : 32:bind-chroot-9.7.0-5.P2.el6.x86_64                     5/6

 Installing     : 32:bind-devel-9.7.0-5.P2.el6.x86_64                      6/6



Installed:

 bind.x86_64 32:9.7.0-5.P2.el6        bind-chroot.x86_64 32:9.7.0-5.P2.el6    

 bind-devel.x86_64 32:9.7.0-5.P2.el6  bind-dyndb-ldap.x86_64 0:0.1.0-0.9.b.el6

 bind-sdb.x86_64 32:9.7.0-5.P2.el6  



Dependency Installed:

 postgresql-libs.x86_64 0:8.4.4-2.el6                                         



Complete!



[root@desktop6 ~]# cd /var/named/chroot/etc/

[root@desktop6 etc]# ls

localtime  named  pki

[root@desktop6 etc]# cd named/

[root@desktop6 named]# ls

[root@desktop6 named]# cd ..

[root@desktop6 etc]# ls

localtime  named  pki

[root@desktop6 etc]# updatedb 



[root@desktop6 etc]# cd /usr/share/doc/

Display all 751 possibilities? (y or n)



[root@desktop6 etc]# cd /usr/share/doc/bind-9.7.0/

arm/                Copyright           draft/              named.conf.default  rfc/                sample/

CHANGES             COPYRIGHT           misc/               README              rfc1912.txt        



[root@desktop6 etc]# cd /usr/share/doc/bind-9.7.0/sample/

etc/ var/

[root@desktop6 etc]# ls /usr/share/doc/bind-9.7.0/sample/etc/named.conf 

localtime  named/     pki/      



[root@desktop6 etc]# ls

localtime  named  pki

[root@desktop6 etc]# cd named/



[root@desktop6 named]# ls



[root@desktop6 named]# pwd

/var/named/chroot/etc/named



[root@desktop6 named]# 

[root@desktop6 named]# man named.conf

[root@desktop6 named]#



[root@desktop6 named]# man named

[root@desktop6 named]#



[root@desktop6 named]# pwd

/var/named/chroot/etc/named



[root@desktop6 named]# cd ..



[root@desktop6 etc]# vim named.conf

i[root@desktop6 etc]# cp /usr/share/doc/bind-9.7.0/named.conf.default named.conf 

cp: overwrite `named.conf'? y



[root@desktop6 etc]# vim named.conf



[root@desktop6 etc]# cat /usr/share/doc/bind-9.7.0/named.conf.default 

//

// named.conf

//

// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS

// server as a caching only nameserver (as a localhost DNS resolver only).

//

// See /usr/share/doc/bind*/sample/ for example named configuration files.

//



options {

	listen-on port 53 { 127.0.0.1; }; #<============== you need to add your ip address

	listen-on-v6 port 53 { ::1; };

	directory 	"/var/named";

	dump-file 	"/var/named/data/cache_dump.db";

       statistics-file "/var/named/data/named_stats.txt";

       memstatistics-file "/var/named/data/named_mem_stats.txt";

	allow-query     { localhost; }; ###<============= add all the network which will be client to this dns

	recursion yes;



	dnssec-enable yes;	###<============ remove this lines for basic config

	dnssec-validation yes;  ###<============ remove this lines for basic config

	dnssec-lookaside auto;  ###<============ remove this lines for basic config



	/* Path to ISC DLV key */ 

	bindkeys-file "/etc/named.iscdlv.key";   ###<============ remove this lines for basic config

};



logging {

       channel default_debug {

               file "data/named.run";

               severity dynamic;

       };

};



zone "." IN {

	type hint;

	file "named.ca";

};



include "/etc/named.rfc1912.zones";





[root@desktop6 etc]# /etc/init.d/named restart

Stopping named:                                            [  OK  ]

Starting named:                                            [  OK  ]



NOW LET US MAKE SOME BASIC CHANGES FOR FORWARDER DNS.





[root@desktop6 etc]# vim named.conf



AFTER CHANGES THE named.conf look likes as below



[root@desktop6 etc]# cat named.conf 

//

// named.conf

//

// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS

// server as a caching only nameserver (as a localhost DNS resolver only).

//

// See /usr/share/doc/bind*/sample/ for example named configuration files.

//



options {

	listen-on port 53 { 127.0.0.1; 192.168.0.6; };

	listen-on-v6 port 53 { ::1; };

	directory 	"/var/named";

	dump-file 	"/var/named/data/cache_dump.db";

       statistics-file "/var/named/data/named_stats.txt";

       memstatistics-file "/var/named/data/named_mem_stats.txt";

	allow-query     { localhost; 192.168.0.0/24; };

	recursion yes;

};





zone "." IN {

	type hint;

	file "named.ca";

};



include "/etc/named.rfc1912.zones";



[root@desktop6 etc]#



NOTE : BEFORE TESTING YOUR DNS PLEASE CHECK TO PING ANY SITE ON INTERNET, CHECK YOUR GATEWAY PROPERLY.



NOW GIVE FOLLOWING COMMAND FOR TESTING THE BASIC DNS



[root@desktop6 etc]# dig @localhost www.google.com



; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6 <<>> @localhost www.google.com

; (2 servers found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41729

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0



;; QUESTION SECTION:

;www.google.com.			IN	A



;; ANSWER SECTION:

www.google.com.		604800	IN	CNAME	www.l.google.com.

www.l.google.com.	300	IN	A	209.85.231.104



;; AUTHORITY SECTION:

google.com.		172800	IN	NS	ns2.google.com.

google.com.		172800	IN	NS	ns4.google.com.

google.com.		172800	IN	NS	ns3.google.com.

google.com.		172800	IN	NS	ns1.google.com.



;; Query time: 116 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Thu Mar 24 03:46:47 2011

;; MSG SIZE  rcvd: 140



[root@desktop6 etc]# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br0

192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 br0

0.0.0.0         192.168.0.254   0.0.0.0         UG    0      0        0 br0



LET US NOW ADD CONFIGURATION FOR FORWARDER 



[root@desktop6 etc]# vim named.conf 





[root@desktop6 etc]# cat named.conf 

//

// named.conf

//

// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS

// server as a caching only nameserver (as a localhost DNS resolver only).

//

// See /usr/share/doc/bind*/sample/ for example named configuration files.

//



options {

	listen-on port 53 { 127.0.0.1; 192.168.0.6; };

	listen-on-v6 port 53 { ::1; };

	directory 	"/var/named";

	dump-file 	"/var/named/data/cache_dump.db";

       statistics-file "/var/named/data/named_stats.txt";

       memstatistics-file "/var/named/data/named_mem_stats.txt";

	allow-query     { localhost; 192.168.0.0/24; };

	recursion yes;

	forward only;

	forwarders { 192.168.0.254; };

};



###

###zone "." IN {

###	type hint;

###	file "named.ca";

###};

###

###include "/etc/named.rfc1912.zones";



[root@desktop6 etc]#





[root@desktop6 etc]# /etc/init.d/named restart

Stopping named:                                            [  OK  ]

Starting named:                                            [  OK  ]





NOW RECORDS ON MASTER DNS ON 192.168.0.254 CAN BE QUERY AND TEST



[root@desktop6 etc]# dig desktop9.example.com



; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6 <<>> desktop9.example.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16311

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1



;; QUESTION SECTION:

;desktop9.example.com.		IN	A



;; ANSWER SECTION:

desktop9.example.com.	86400	IN	A	192.168.0.9



;; AUTHORITY SECTION:

example.com.		86400	IN	NS	instructor.example.com.



;; ADDITIONAL SECTION:

instructor.example.com.	86400	IN	A	192.168.0.254



;; Query time: 0 msec

;; SERVER: 192.168.0.254#53(192.168.0.254)

;; WHEN: Thu Mar 24 03:49:08 2011

;; MSG SIZE  rcvd: 95



IF MASTER DNS 192.18.0.254 WILL NOT ALLOWED OUR FORWARDER DNS IT CAN NOT CHECK THE ADDRESSES ON INTERNET



[root@desktop6 etc]# dig www.google.com



WAITING ONLY ...



Thats it.



Imprtant reference



1. man named.conf

2. man named

3. directory /usr/share/doc/bind-******/

4. /usr/share/doc/bind-9.7.0/arm/Bv9ARM.pdf

5. /usr/share/doc/bind-9.7.0/sample/

6. /usr/share/doc/bind-9.7.0/sample/etc/

7. /usr/share/doc/bind-9.7.0/sample/var/

Kerberos Authentication With SSH Application

In any network communication, the two stages that the user has to pass through, for getting connected to a remote system and getting access to the resources on the remote system are "Authentication" and "Authorization". Authentication is "the process of verifying an identity claimed by or for a system entity". This is to provide assurance that users (or systems) are who they say they are. Thus, authentication process compares, what user has, to a known constant that is trusted. Most of the time this is done by interacting with the user like getting the username and password. Other forms with the by proxy such as smartcard where the authentication tokens will be stored. These standards are described in RFC 2828 (Internet Security Glossary, May 2000). Authorization refers to a user's ability to access resources on a network, based on user account privileges and rights. This is also known as "access control". Only a user who succeeded in authentication will enter to this authorization phase.
Overview of Kerberos	Kerberos, developed and released by MIT, is an AA [Authentication and Authorization] system. Kerberos has two purposes, security and authentication. In most distributed network system, most of the time, password is used to prove user's identity, and password must be transmitted over the network from the client machine to the machine that the user wants to access. So, a mechanism that prevent anyone from intercepting or eavesdropping on the transmitted plain passwords is vital for security. Also another pain in using password for the authentication is, the password has to be supplied each and every time a connection is requested to the remote machine. Kerberos help users to avoid this pain and the central problem solved by Kerberos is how to use passwords for authentication without sending them over the network. The following infrastructure are required for setting up a Kerberos environment Key Distribution Centre [KDC]: KDCs are central to the Kerberos system and this system should be heavily secured. This system should run KDC only and other remote logins should be denied. If at all it is desired to allow remote login, SSH is preferred. This system should be kept in a physically secure location. Slave KDC [For backup]: Kerberos cannot operate without a KDC. So, it is good to have a backup system for the main KDC and this can be act as a slave. This host will synchronize periodically with the master KDC and if the master host fails, this slave will takeover the control. Once a KDC host is ready, proper configurations should be done for using this with OpenSSH. More details are given here - KDC configuration Although Kerberos provides some minimal level of authorization facilities, it is limited only for the permissions that the user can have to modify the KDC database. Thus, the individual applications need to take care of the authorization part. This document is mainly for guiding users in configuring Kerberos to use with OpenSSH. For more information about Kerberos and other terms discussed about Kerberos, click here - "How Kerberos authentication works?".
Overview of OpenSSH	OpenSSH, primarily developed by the OpenBSD Project, is a free version of the SSH protocol suite of network connectivity tools. OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, IP spoofing and other network level attacks. This distribution provides many authentication methods and one among that is the Kerberos authentication. OpenSSH and HP-UX Secure Shell supports SSH Protocol versions 1.3, 1.5 and 2.0. As per the current version of OpenSSH [4.3p2],the Kerberos authentication is done via their Kerberos credentials and the authenticated users are allowed to forward their credentials to a remote machine over ssh. Kerberos authentication support is available for SSH protocols 1 and 2. For SSH protocol 2.0, GSSAPI support is also available. In addition to other authentication mechanism support, GSSAPI facilitates authentication with Kerberos also.
Common Definitions	Before getting into the details of configuration, some of the definitions to be known. Realm: The realm is an administrative division identifying a single instance of Kerberos principal database. Each host is given a realm name. If you are maintaining a KDC for your domain xyz.org, then the realm is the name for the host on which this KDC service is running. Realm names are usually in capital letters [normal convention]. So, the realm name for your example domain is XYZ.ORG. This realm will have a database that holds the user principals. Principal: A principal is essentially a username for the realm. Each user needs a principal in the realm. This is of the form, principal_name@REALM. For example, sshteam@VISOLVE.COM. In addition to a principal, you must have an account on each machine in the network that comes under this realm, that you will use. If the principal name and the account name are the same, then there are more conveniences. Ticket: A record that helps a client authenticate itself to a server; it contains the client's identity, a session key, a timestamp, and other information, all sealed using the server's secret key. It only serves to authenticate a client when presented along with a fresh Authenticator. TGT: Ticket Granting ticket is issued by AS [Authentication Server - a component in KDC], to client for the desired application service, which is encrypted by the client's secret key.
Configuring the Kerberos environment	The following are the requirements for setting up Kerberos on Linux [to use with OpenSSH] A KDC, Application Server and an Application Client. We have used three Linux machines to demonstrate this setup. The OpenSSH client and Server machines are referred as Application client and Application Server machines respectively. Kerberos should be installed on all the three machines All the machines should contain krb5.conf file in the /etc directory and make sure that the krb5.conf file is common for all the 3 machines. DNS should be configured for all the server and client host entries. Clock synchronization should be working on the kerberos server [KDC]. The time difference between the client and server machine clocks is configurable in Kerberos 5. A keyword "clockskew" can be set (in seconds), under the [libdefaults] section in /etc/krb5.conf file, with the value for the difference in time that will be tolerated by the server. The default is 300 seconds [5 minutes]. If the clocks are different by more than 5 minutes, the Kerberos clients will not be able to authenticate to the server. You need to setup a Network Time Protocol compatible client/server network between the three machines. More details on how to setup NTP is available at http://www.ntp.org/documentation.html. To demonstrate the steps, we have used the following names for the systems in the network. XYZ.ORG Realm name. The domain the KDC is running for. kdcserver.xyz.org The hostname where KDC is running sshserver.xyz.org The ssh server hostname sshclient.xyz.org The ssh client hostname krbuser A user. The principal for this user has to be added to the KDC, and this user must have an account on the sshserver.xyz.org. The following steps have to be followed to install Kerberos on all the machines, the KDC system, the Server [where SSH server is installed] and the Client machine where SSH client is installed.. The Kerberos installation steps may vary from one Linux distribution to the other. If an rpm is available for Kerberos in the Linux distribution you are using, then install that rpm on all the systems.
Installing Kerberos	Installing Kerberos from source or rpm The following rpms have to be installed. The versions numbers may differ. Here, the version taken is "1.2.7-10". This is taken on Redhat 9.0. krb5-devel-1.2.7-10.i386.rpm krb5-libs-1.2.7-10.i386.rpm krb5-workstation-1.2.7-10.i386.rpm The command to install an rpm on Linux is given below. # rpm -ivh Otherwise, follow these instructions to build Kerberos on your Linux Systems. Download the latest Kerberos 5 source [ http://www.crypto-publish.org/mit-kerberos5/] Copy the source tar file to /usr/local [You can select other locations also] You must be a "root" user for performing the following operations cd /usr/local tar -xvzf krb5-1.3.1.tar.gz [Ex: We have used 1.3.1 version of Kerberos5 source] cd krb5-1.3.1 ./configure--prefix=/usr/local/krb5 make make install As explained already, KDC is the main component of Kerberos. The host that runs the KDC will have a name [Realm] and this consists of a database [list of principals]. The following steps have to be followed for configuring the KDC.
Configuring the KDC	Configuring the KDC Create a directory krb5kdc in /usr/local/krb5/var Copy the kdc.conf file from /usr/local/krb5-1.3.1/src/config-files to /usr/local/krb5/var/krb5kdc Modify the kdc.conf file for the correct information Create an access control list file kadm5.acl and save the file in /usr/local/krb5/var/krb5kdc Sample configuration files are given here. The kdc.conf and kadm5.acl files must be present in the KDC server. The other file krb5.conf must be present on all the machines. These files reflect the details about the realm, the domain-realm mappings and the access privileges for the principals to access the Kerberos database. To setup your own realm and domain, just replace the XYZ.ORG in all the files with your domain name. By convention, all realm names should be in uppercase letters and all DNS hostnames and domain names should be in lower case letters. KDC Configuration file : kdc.conf # /etc/kdc.conf - Kerberos Key Distribution Center - Configuration File [kdcdefaults] kdc_ports = 88 [realms] XYZ.ORG = { kadmind_port = 749 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s admin_keytab=/usr/local/krb5/var/krb5kdc/kadm5.keytab acl_file=/usr/local/krb5/var/krb5kdc/kadm5.acl master_key_type = des3-hmac-sha1 supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des-cbc-crc:v4 kdc_supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des-cbc-crc:v4 } [logging] kdc = FILE:/usr/local/krb5/var/krb5kdc/kdc.log admin_server = FILE:/usr/local/krb5/var/krb5kdc/kadmin.log
	ACL - Access Control List : kadm5.acl # /usr/local/var/krb5/krb5kdc/kadm5.acl - Access Control List configuration File */admin@XYZ.ORG * /etc/krb5.conf # /etc/krb5.conf - Kerberos client Configuration File [logging] default = FILE:/usr/local/krb5/var/log/krb5lib.log kdc = FILE:/usr/local/krb5/var/log/krb5kdc.log admin_server = FILE:/usr/local/krb5/var/log/kadmin.log [libdefaults] ticket_lifetime = 24000 default_realm = XYZ.ORG dns_lookup_realm = false dns_lookup_kdc = false [realms] XYZ.ORG = { kdc = kdcserver.xyz.org:88 admin_server = kdcserver.xyz.org:749 default_domain = xyz.org } [domain_realm] .xyz.org = XYZ.ORG xyz.org = XYZ.ORG [kdc] profile = /usr/local/krb5/var/krb5kdc/kdc.conf [pam] debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false Managing KDC database [ Creating KDC database, Adding user principals ] 1. First a database has to be created in the KDC host to hold the principals of the users and hosts. The command given here will create the database files. These files will be created in /usr/local/krb5/var/krb5kdc/. # /usr/local/krb5/sbin/kdb5_util create -r XYZ.ORG -s 2. This realm [KDC host] needs an administrator. Thus, an entry has to be added in the database for the administrator. The following command do that job. # /usr/local/krb5/sbin/kadmin.local -q "addprinc useradmin/admin@XYZ.ORG" Passwd: * * * * * * 3. The next step is to create a keytab for kadmind [the Kerberos administration server]. This keytab is a file where user keys will be stored and this key will be used by the kadmind to decrypt the administrators Kerberos tickets to determine whether or not it should give the database. This is done with the following command. # /usr/local/krb5/sbin/kadmin.local -q \ "ktadd -k /usr/local/var/krb5kdc/kadm5.keytab =>kadmin/admin kadmin/changepw" 4. For every user in the network, if the user wants to connect to another machine with Kerberos authentication, then, the user must have a principal in the KDC. The following commands are used to add a principal for the user in the KDC database. There must be an user account in the server to which the user wants to connect with this Kerberos principal. For conveniencies, it is recommended to have same names for the user account in the server and the principal name in KDC. [See Principal]. # /usr/local/krb5/sbin/kadmin.local -q "addprinc krbuser" 5. Thus, the KDC is configured with a user principal for the user "krbuser". Once this is done, the Kerberos server has to be started. # /usr/local/krb5/sbin/krb5kdc # /usr/local/krb5/sbin/kadmind
Configuring the Application Server System	Configuring the Application server system: The Application server need a keytab file, called /etc/krb5.keytab, to authenticate to the KDC. In order to generate a keytab for a host, the host must have a principal in the Kerberos database. Follow the procedure for adding hosts to the database. Application server [SSH Server machine] 1.Get the ticket from the KDC for the administrator principal. This command will result in a prompt for the admin password. Give a password for the admin. # /usr/local/krb5/bin/kinit admin/admin Passwd: * * * * * * 2. Now, the principal of the server [sshserver.xyz.org] must be added to the KDC. # /usr/local/krb5/sbin/kadmin.local -q "addprinc -randkey host/sshserver.xyz.org" 3. Create a keytab file.This will create a keytab file in /etc/krb5.keytab. # /usr/local/krb5/sbin/kadmin.local -q " ktadd -k /etc/krb5.keytab host/sshserver.xyz.org" 4. Check the correct information in the keytab file. ktutil is an utility for managing the keylist in keytab files. "rkt" means read keytab. "l" lists the current keylist in the keytab file. To know the correct server principal entry in the keytab file, ktutil command is used. "q" is used to quit from the kutil service. # /usr/local/krb5/sbin/ktutil ktutil: rkt /etc/krb5.keytab ktutil: l slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 3 host/sshserver.xyz.org@XYZ.ORG 2 3 host/sshserver.xyz.org@XYZ.ORG ktutil: q
Configuring the Application Client System	Configuring the Application client system Client machine needs the programs "kinit", "klist", "kdestroy" and the /etc/krb5.conf file which contains the KDC server details. The installation of kerberos-1.3.1 creates all the client programs in /usr/local/krb5/bin
OpenSSH Authentications	OpenSSH Authentications Kerberos5 server can be used for the following authentications with OpenSSH. GSS-API Authentication Kerberos5 Authentication OpenSSH must be available on the client and server machines. [on sshclient.xyz.org and sshserver.xyz.org respectively]. For more details about OpenSSH build and installation, see OpenSSH installation on Linux. GSS-API Authentication 1. Edit the ssh server configuration file [by default, in /etc/ssh/sshd_config] on sshserver.xyz.org and ssh client configuration file [by default, in /etc/ssh/ssh_config] on sshclient.xyz.org. If you had given a different installation path for the OpenSSH application, then check sshd_config in "etc"directory in the installed path. GSSAPIAuthentication yes 2. Start the sshd server on sshserver.xyz.org. By default the ssh server will run on port 22. # /user/sbin/sshd 3. Make sure that the kdc server is running in the KDC machine , [kdcserver.xyz.org] # ps -A |grep krb5kdc If the server is not started, start by # /usr/local/krb5-1.3.1/sbin/krb5kdc # /usr/local/krb5-1.3.1/sbin/kadmind 4. Get a initial ticket ( TGT ) in the client machine [sshclient.xyz.org] # kinit krbuser Passwd: * * * * * * 5. Once a TGT is obtained, it can be checked as follows. # klist Ticket cache: FILE:/tmp/krb5cc_11190 Default principal: krbuser@XYZ.ORG Valid starting Expires Service principal 01/09/04 12:41:09 01/09/04 22:41:09 krbtgt/XYZ.ORG@XYZ.ORG 6. Connect the ssh client with the server # ssh krbuser@sshserver.xyz.org Note: GSS-API authentication is a password less authentication. For a successful connection, the server should not ask for a password for the authentication. But, other authentications such as Publickey will also connect without password if there is proper key on the client and server. To make sure that GSS-API authentication is succeeded,the ssh client can be run in verbose mode. This can be done by using "-v" with the ssh client. The more the number of "v", the more the verbose details. The maximum number of "v" that can be given is 3. # ssh krbuser@sshserver.xyz.org -vvv ...... debug1: Authentication succeeded (gssapi)
Kerberos Authentication	Kerberos5 Authentication 1. Edit the ssh server configuration file [by default, in /etc/ssh/sshd_config] on sshserver.xyz.org and ssh client configuration file [by default, in /etc/ssh/ssh_config] on sshclient.xyz.org. If you had given a different installation path for the OpenSSH application, then check sshd_config in "etc" directory in the installed path. KerberosAuthentication yes 2. Start the sshd server on sshserver.xyz.org. By default the ssh server will run on port 22. # /usr/sbin/sshd 3. Make sure that the kdc server is running in the KDC machine , [kdcserver.xyz.org] # ps -A |grep krb5kdc If the server is not started, start by # /usr/local/krb5-1.3.1/sbin/krb5kdc # /usr/local/krb5-1.3.1/sbin/kadmind 4. Destroy the ticket in the client machine # kdestroy 5. Connect the ssh client with the server. # ssh krbuser@sshserver.xyz.org Note: In this authentication, the user will be prompted for a password. The password to be entered should be the "Kerberos password". This is the password that is used when "kinit" is done.
RFCs for Kerberos	RFC 1510 The Kerberos Network Authentication Service [V5] RFC 1964 The Kerberos Version 5 GSS-API mechanism RFC 1305 Network Time Protocol
References	http://web.mit.edu/kerberos/www/ - Kerberos home page on MIT http://web.mit.edu/kerberos/www/dialogue.html - A good explanation of Kerberos protocol, in plain english. The conversation style is intended to introduce the concept for people who are unfamiliar with Kerberos. Technical details are kept minimum. http://www.cs.uu.nl/wais/html/na-dir/kerberos-faq/general.html - Kerberos FAQs Book - "SSH,The Secure Shell: The Definitive Guide". Authors : Daniel J. Barrett and Richard E. Silverman.