solaris 10, let's switch your name and numbers

Changing the IP on Solaris 10 requires editing two files:
/etc/hosts
/etc/inet/ipnodes


If the router's address is here:
/etc/defaultrouter


Changing the hostname on Solaris requires editing the following:
/etc/hosts
/etc/nodename
/etc/hostname.


is the driver name followed by the instance number of the interface, i.e. hme0, bge0, ce0, qfe0

Network interfaces by driver name and instance# may be discovered by issuing:
prtconf -D | grep network


The following hosts files are no longer used in Solaris 10 - but are current in our friends Solaris 8 & 9:
/etc/net/ticlts/hosts
/etc/net/ticots/hosts
/etc/net/ticotsord/hosts

Reboot the system to bring up the new IP and hostname.

sshd and LDAP for authentication control

LDAP can be used for group authentication on individual systems; however the directives in /etc/ssh/sshd_config:

AllowGroups
AllowUsers


Are mutually exclusive, with the AllowUsers directive taking precedence over AllowGroups; moreover, local and LDAP groups may be mixed in the AllowGroups directive.  Meaning if you're to use AllowGroups and wish to allow root logon, place local group "root" in the AllowGroups directive.

Using the AllowGroups directive is a far better way of giving discrete users access to a system as opposed to relying upon the placement individual entries in sshd_config if the system is an LDAP client.

Here's what an erroneous ssh attempt with a non-group member (in this case root) shows:
Jul 20 13:41:35 server sshd[2541]: User root from client not allowed because none of user's groups are listed in AllowGroups
Jul 20 13:41:35 server sshd[2541]: Failed none for invalid user root from client port 41466 ssh2
Jul 20 13:41:37 server sshd[2541]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=client user=root
Jul 20 13:41:39 server sshd[2541]: Failed password for invalid user root from client port 41466 ssh2


Here's what an LDAPed user (ldapuser) looks like, falling through the PAM stack and gaining logon:
Jul 20 13:45:46 server sshd[2703]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=client  user=ldapuser
Jul 20 13:45:46 server sshd[2703]: Accepted password for ldapclient from client port 41529 ssh2

how to figure linux flavor

Not all linucies have the same means of determining their version; uname -a doesn't always cut it:

SuSE/SLES:
# cat /etc/SuSe-releases
# rpm -qf /boot/vmlinuz
# SPident -vv

likewise is fun

sometimes i like to make my linux boxes join active directory domains.  just because.  the whole goofing around with native kerberos setups can be a bear, especially when you have to start throwing around service account credentials on untrusted systems.  likewise is a good candidate to get around that whole hornet nest.  and!  since we're using linux, your nsswitch and pam stacks can still call ldap; just make sure you've got the correct precedence down.

here're some of my notes from a problem install...

* getting likewise best via wget; otherwise possibly will receive md5 checksum integrity errors.

* system must have perm name even if DHCP client; rhel set in /etc/sysconfig/network
HOSTNAME=fqdn

* if receive error after issuing:
/opt/likewise/bin/domainjoin-cli join DOMAIN account 
Error: Lsass Error [code 0x00080047]
maybe an artifact of clocks being off, vid.:
http://www.likewise.com/community/index.php/forums/viewthread/269/

solution; synch clocks.  try again.

* ad domain should be in fqdn and ms-dns reachable by client.

...

during process of joining domain, likewise complains of segfault.
system did join domain; tested domain and did see correct ad entries and krb ticket exchanges.
user able to auth as others via local system; not so via remote means.

after further debugging, noticed a lack of pam.d configuration changes.
segfault was probably related to /lib/security (pam modules); as debugging auth processes via ssh
found that the likewise provided object for pam is faulty.

the same problem is probably related to vintela subsystem not honoring ssh logons, only su commands.
solution:  remove pam_vas3.so from entries in pam.d conf files.

...

order of likewise re-starts:
1. netlogond
2. lwiod
3. dcerpcd
4. eventlogd
5. lsassd

* strict order

...

likewise nsswitch config:

passwd:     files lsass
shadow:     files
group:      files lsass

hosts:      files dns

bootparams: files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files
netgroup:   files
publickey:  files
automount:  files
aliases:    files

* throw ldap entries after likewise.

otherwise, this error'll appear:

Error: Manual configuration required [code 0x0000a606]

The configuration stage 'enable/disable Likewise nsswitch module' cannot be completed automatically. Please manually perform the
following steps and rerun the domain join:

Remove the passwd_compat and/or group_compat lines and use passwd and group instead. This cannot be done automatically because your
system has a non-default nsswitch configuration.

...

likewise user directories conf is here: /etc/likewise/lsass.conf

order of operation, automake of dirs doesn't always work...

# mkdir user
# chown TEST-AD\\user.users user
# su - TEST-AD\\user
$ touch new
$ ls -la

drwxr-xr-x  2 TEST-AD\user     users              4096 Aug  7 15:07 .
drwxr-xr-x  3 root             root               4096 Aug  7 15:06 ..
-rw-r--r--  1 TEST-AD\user     TEST-AD\domain^users    0 Aug  7 15:07 new

...

time; are the clocks between client & ad controller in sync? five minute differences = expired kerberos tickets.

check resolv.conf;  is the ms-dns server present? must be able to contact to determine srv reconds

nsswitch; make certain dns is present for hosts.  files alone won't cut it.

...

likewise is supposed to auto-create dirs when the appropriate 
user logs on.
ssh in as test-ad\\uid ; e.g.:
ssh test-ad\\test@test01

notice the pwd.  defined test-ad account home as /opt/TEST-AD/uid
this is defined here:  /etc/likewise/lsass.conf

uids are case sensitive
uids are wacky; since they take after windows sid
if you're on the system, try:  getent passwd test-ad\\test
TEST-AD\test01:x:1032324191:1032323585:qa:/opt/TEST-AD/test:/bin/bash

i've added test-ad\\test to the sudoers file

if changes are made to /etc/likewise/lsass.conf (don't) or 
if there are logon issues, issue the following:
# /sbin/service lsassd stop
# rm -f /var/lib/likewise/db/lsass-adcache.db
# rm -f /var/lib/likewise/db/lsass-local.db
# /sbin/service lsassd start

curious about domain account status:
# /opt/likewise/bin/domainjoin-cli query
Name = test01
Domain = TEST-AD.TLD
Distinguished Name = CN=TEST,CN=Computers,DC=test-ad,DC=TLD

a graceful pseudo interface for debian...

This summary is not available. Please click here to view the post.

stop sshd from doing reverse lookups

When you've a DMZ, there's nothing more painful than your hosts trying to do a reverse lookup for a system of which they've no knowledge.  So, halting sshd from doing reverse DNS lookups will speed things along.

In /etc/ssh/sshd_config file, the default answer is yes; and if this line not shown in the config file, add it:

UseDNS no

By default, this directive tells the sshd process to check resolved host name for the connected client's IP address maps back to the very same IP address or not.  "no" tells it to do the opposite. 

Older sshd daemons use:

VerifyReverseMapping no

However, it does not prevent the sshd server from performing any DNS lookups at all. That's not the purpose of that directive.  In order to remove DNS lookups completely, you have to use  the -u0 option when starting sshd server. So...

On RHEL, in /etc/sysconfig/sshd add:

OPTIONS="-u0"

On SLES boxes, in /etc/sysconfig/ssh add:

SSHD_OPTS="-u0"

On Ubuntu boxes, in /etc/default/ssh add:

SSHD_OPTS="-u0"

This option will has the sshd daemon not put hostnames into the utmp structure (what you see when you type "who" at the shell prompt) - which means that sshd will not perform DNS lookups for that purpose. However (there's always a however) there are still cases where a lookup has to be performed, such as when a user has

"from="

and like entries in the authorized_keys file, or when authentication methods or configuration directives are used that involve hostnames.  Keeping that in mid...