Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Solaris Trusted Extensions Administrator's Procedures
Previous Next

Troubleshooting the Trusted Network (Task Map)

The following task map describes tasks to debug your network.

Task

Description

For Instructions

Determine why two hosts cannot communicate.

Checks that the interfaces on a single system are up.

How to Verify That a Host's Interfaces Are Up

Uses debugging tools when two hosts cannot communicate with each other.

How to Debug the Trusted Extensions Network

Determine why an LDAP client cannot reach the LDAP server.

Troubleshoots the loss of connection between an LDAP server and a client.

How to Debug a Client Connection to the LDAP Server

How to Verify That a Host's Interfaces Are Up

Use this procedure if your system does not communicate with other hosts as expected.

Before You Begin

You must be in the global zone in a role that can check network settings. The Security Administrator role and the System Administrator role can check these settings.

  1. Verify that the system's network interface is up.

    The following output shows that the system has two network interfaces, hme0 and hme0:3. Neither interface is up.

    # ifconfig -a
    ...
    hme0: flags=1000843<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
             inet 192.168.0.11 netmask ffffff00 broadcast 192.168.0.255
    hme0:3 flags=1000843<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
             inet 192.168.0.12 netmask ffffff00 broadcast 192.168.0.255
  2. If the interface is not up, bring it up and then verify that it is up.

    The following output shows that both interfaces are up.

    # ifconfig hme0 up
    # ifconfig -a
    ...
    hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,...
    hme0:3 flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,..

How to Debug the Trusted Extensions Network

To debug two hosts that should be communicating but are not, you can use Trusted Extensions and Solaris debugging tools. For example, Solaris network debugging commands such as snoop and netstat are available. For details, see the snoop(1M) and netstat(1M) man pages. For commands that are specific to Trusted Extensions, see Table 8-4.

Before You Begin

You must be in the global zone in a role that can check network settings. The Security Administrator role or the System Administrator role can check these settings.

  1. To troubleshoot the tnd daemon, change the polling interval and collect debugging information.

    For details, see the tnd(1M) man page.

  2. Check that the hosts that cannot communicate are using the same naming service.
    1. On each host, check the nsswitch.conf file.
      1. Check the values for the Trusted Extensions databases in the nsswitch.conf file.

        For example, at a site that uses LDAP to administer the network, the entries are similar to the following:

        # Trusted Extensions
        tnrhtp: files ldap
        tnrhdb: files ldap
      2. If the values are different, correct the nsswitch.conf file.

        To modify these entries, the system administrator uses the Name Service Switch action. For details, see How to Start CDE Administrative Actions in Trusted Extensions. This action preserves the required DAC and MAC file permissions.

    2. Check that the LDAP naming service is configured.
      $ ldaplist -l
    3. Check that both hosts are in the LDAP naming service.
      $ ldaplist -l hosts | grep hostname
  3. Check that each host is defined correctly.
    1. Use the Solaris Management Console to verify the definitions.
      • In the Security Templates tool, check that each host is assigned to a security template that is compatible with the security template of the other host.

      • For an an unlabeled system, check that the default label assignment is correct.

      • In the Trusted Network Zones tool, check that the multilevel ports (MLPs) are correctly configured.

    2. Use the command line to check that the network information in the kernel is current.

      Check that the assignment in each host's kernel cache matches the assignment on the network, and on the other host.

      To get security information for the source, destination, and gateway hosts in the transmission, use the tninfo command.

      • Display the IP address and the assigned security template for a given host.
        $ tninfo -h hostname
        IP Address: IP-address
        Template: template-name
      • Display a template definition.
        $ tninfo -t template-name
        template: template-name
        host_type: one of CIPSO or UNLABELED
        doi: 1
        min_sl: minimum-label
        hex: minimum-hex-label
        max_sl: maximum-label
        hex: maximum-hex-label
      • Display the MLPs for a zone.
        $ tninfo -m zone-name
        private: ports-that-are-specific-to-this-zone-only
        shared: ports-that-the-zone-shares-with-other-zones
  4. Fix any incorrect information.
    • To change or check network security information, use the Solaris Management Console tools. For details, see How to Open the Trusted Networking Tools

    • To update the kernel cache, restart the tnctl service on the host whose information is out of date. Allow some time for this process to complete. Then, refresh the tnd service. If the refresh fails, try restarting the tnd service. For details, see How to Synchronize the Kernel Cache With Trusted Network Databases.

      Rebooting clears the kernel cache. At boot time, the cache is populated with database information. The nsswitch.conf file determines whether local databases or LDAP databases are used to populate the kernel.

  5. Collect transmission information to help you in debugging.
    • Verify your routing configuration.

      Use the get subcommand to the route command.

      $ route get [ip] -secattr sl=label,doi=integer

      For details, see the route(1M) man page.

    • View the label information in packets.

      Use the snoop -v command.

      The -v option displays the details of packet headers, including label information. This command provides a lot of detail, so you might want to restrict the packets that the command examines. For details, see the snoop(1M) man page.

    • View the routing table entries and the security attributes on sockets.

      Use the -R option with the netstat -a|-r command.

      The -aR option displays extended security attributes for sockets. The -rR option displays routing table entries. For details, see the netstat(1M) man page.

How to Debug a Client Connection to the LDAP Server

Misconfiguration of the client entry on the LDAP server can prevent the client from communicating with the server. Similarly, misconfiguration of files on the client can prevent communication. Check the following entries and files when attempting to debug a client-server communication problem.

Before You Begin

You must be in the Security Administrator role in the global zone on the LDAP client.

  1. Check that the remote host template for the LDAP server and for the gateway to the LDAP server are correct.
    # tninfo -h LDAP-server
    # route get LDAP-server
    # tninfo -h gateway-to-LDAP-server

    If a remote host template assignment is incorrect, assign the host to the correct template by using the Security Templates tool in the Solaris Management Console.

  2. Check and correct the /etc/hosts file.

    Your system, the interfaces for the labeled zones on your system, the gateway to the LDAP server, and the LDAP server must be listed in the file. You might have more entries.

    Look for duplicate entries. Remove any entries that are labeled zones on other systems. For example, if Lserver is the name of your LDAP server, and LServer-zones is the shared interface for the labeled zones, remove LServer-zones from /etc/hosts.

  3. If you are using DNS, check and correct the entries in the resolv.conf file.
    # more resolv.conf
    search list of domains
    domain domain-name
    nameserver IP-address
    
    ...
    nameserver IP-address
  4. Check that the tnrhdb and tnrhtp entries in the nsswitch.conf file are accurate.
  5. Check that the client is correctly configured on the server.
    # ldaplist -l tnrhdb client-IP-address
  6. Check that the interfaces for your labeled zones are correctly configured on the LDAP server.
    # ldaplist -l tnrhdb client-zone-IP-address
  7. Verify that you can ping the LDAP server from all currently running zones.
    # ldapclient list
    ...
    NS_LDAP_SERVERS= LDAP-server-address
    # zlogin zone-name1 ping LDAP-server-address
    LDAP-server-address is alive
    # zlogin zone-name2 ping LDAP-server-address
    LDAP-server-address is alive
    ...
  8. Configure LDAP and reboot.
    1. Run the Create LDAP Client action.

      This action re-establishes the global zone as a client of the LDAP server.

    2. In every labeled zone, re-establish the zone as a client of the LDAP server.
      # zlogin zone-name1
      # ldapclient init \
      -a profileName=profileName \
      -a domainName=domain \
      -a proxyDN=proxyDN \
      -a proxyPassword=password LDAP-Server-IP-Address
      # exit
      # zlogin zone-name2 ...
    3. Halt all zones, lock the file systems, and reboot.

      If you are using Solaris ZFS, halt the zones and lock the file systems before rebooting. If you are not using ZFS, you can reboot without halting the zones and locking the file systems.

      # zoneadm list
      # zoneadm -z zone-name halt
      # lockfs -fa
      # reboot
Previous Next

 
 
  Published under the terms fo the Public Documentation License Version 1.01. Design by Interspire