annoying pkgadd dependency chains be gone

one of the bum deals about pkgadd - sun's answer, i guess to rpm installs - is that you can try to add a package to a system and the install can fail if you don't have all the right dependencies. however, now some coolio folks wrote a util that downloads and checks dependencies if you're grabbing the open software from opencsw.

here's how to get pkgutil and install, say libstdc++5

# pkgadd -d http://get.opencsw.org/now
# vi ~/.bash_profile 

add /opt/csw/bin to your path

# pkgutil -i libstdc++5

crap.  it installs to /opt/csw/bin.

# ln -s /opt/csw/lib/libstdc++.so.5 /usr/lib
# ln -s /opt/csw/lib/libstdc++.so.5.0.5 /usr/lib

likewise, ms sfu + 2307 attributes & ldap

disgusting.

so, as you're probably aware, likewise-open is a nifty tool for getting authentication of linux and linuxesque boxes to active directory. likewise-open is placed in the ecosystem where admins simply need authentication and home directories mounted. it uses an internal hash mechanism to auto-generate uids and gids from user sids in active directory; so, in essence, all across an enterprise, the likewise-open uids and gids will be the same. okay. sure.

but what about mixed el-cheapo shops?

my problem was the following:
i have a windows active directory domain and i have a linux-based openldap system. i've invested heavily in both, so, i'm really not in the mood to retire or re-tool the linux side of the house. windows, sure. the end goal is to have a linux machine join active directory and be able to authenticate windows users preserving openldap uid and gids.

i do not want to use samba, i do not want to use winbind, i do not want to use likewise-open weird hash mechanisms. i do want to use RFC 2307 attributes.

microsoft ad's nice, as there's actually a schema extension that enables an admin to have unix uids and gids. this is accessible once idmu extensions are rendered visible and server for nis is installed. oh yes.

here's what i did:
1. on ms server 2003 ad controller, installed ms sfu 3.5 server for nis.
2. ditto, installed ms idmu extensions.
3. opened my ldap db and took note of my user uids and gids.
4. i now have something called, "services for unix authentication"
the domain is the short nt-namr for my ad domain. nice.
5. my ad entries now have the nifty tab, "UNIX Attributes"
6. added the proper uid & gid information as gleaned from ldap to each of my ad records.
i don't have many users to think about, so doing this by hand is a piece of cake.
7. on a linux box, i did the usual likewise-open installation.
we really just want the kerberos ticket generation stuff, so we don't have to
go to an ad server and run kerberos ticket utilities and the like. turn-key is
the name of the game.
8. edited several key files... ldap.conf, nsswitch.conf, krb5.conf

ldap.conf: we're pointing to the ad controller. we have cool rfc 2307 attributes defined here, too.
nsswitch.conf: remove lsass entries, it'll only prove to confuse things.
krb5.conf: get the ad controller in there.

just for fun, do an ldap search against your ad controller with a bind account. you
know and i know that ad will not allow searches by anonymous users. having ntp have its
time source set by the ad controller would be awesome, too.

here's a nice search:

# ldapsearch -x -D "notme@not.there.com" -w badpassword -h 10.0.0.1

you should see:

# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 10 Referral
text: 0000202B: RefErr: DSID-031006E0, data 0, 1 access points
        ref 1: 'not.here.com'

ref: ldap://not.there.com/dc=not,dc=there,dc=com

# numResponses: 1

here's what my conf files look like:

ldap.conf

host 10.0.0.1
base dc=not,dc=there,dc=com
uri ldap://10.0.0.1/
binddn notme@not.there.com <--- ad doesn't like the whole cn dn deal all the time.
bindpw badpassword
scope sub
bind_timelimit 15
timelimit 15
ssl no
referrals no
nss_base_passwd cn=Users,dc=not,dc=there,dc=com?sub
nss_base_shadow cn=Users,dc=not,dc=there,dc=com?sub
nss_base_group cn=Users,dc=not,dc=there,dc=com?sub?&(objectCategory=group)(gidnumber=*)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute gecos cn
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uniqueMember member
nss_initgroups_ignoreusers ldap

nsswitch.conf

passwd: compat ldap lsass <---- remove
group:  compat ldap lsass <---- remove

hosts:  files dns
networks:       files dns

services:       files ldap
protocols:      files
rpc:    files
ethers: files
netmasks:       files
netgroup:       files ldap
publickey:      files

bootparams:     files
automount:      files nis
aliases:        files ldap
#passwd_compat: ldap
#group_compat:  ldap

krb5.conf

[libdefaults]
        default_realm = NOT.THERE.COM 
        default_keytab_name = /etc/krb5.keytab 
        default_tgs_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC 
        default_tkt_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC 
        preferred_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC 
        dns_lookup_kdc = true 
        pkinit_kdc_hostname =  
        pkinit_anchors = DIR:/var/lib/likewise/trusted_certs 
        pkinit_cert_match = &&msScLogin 
        pkinit_eku_checking = kpServerAuth 
        pkinit_win2k_require_binding = false 
        pkinit_identities = PKCS11:/opt/likewise/lib/libpkcs11.so 

[realms]
        NOT.THERE.COM = {
                auth_to_local = RULE:[1:$0\$1](^NOT\.THERE\.COM\\.*)s/^NOT\.THERE\.COM/NOT/
                auth_to_local = DEFAULT
                kdc = adserver.not.there.com
                admin_server = adserver.not.there.com
        }

[logging]
    kdc = FILE:/var/log/krb5/krb5kdc.log
    admin_server = FILE:/var/log/krb5/kadmind.log
    default = SYSLOG:NOTICE:DAEMON
[domain_realm]
  .not.there.com = NOT.THERE.COM 
[appdefaults]
        pam = {
   mappings = NOT\\(.*) $1@NOT.THERE.COM 
   forwardable = true
   validate = true
        }
        httpd = {
   mappings = NOT\\(.*) $1@NOT.THERE.COM 
   reverse_mappings = (.*)@NOT\.THERE\.COM NOT\$1
        }

osx 10.7.2 openldap authentication

MacOSX 10.7.2 LDAP authentication

0.  Enable root.
* Go to a terminal prompt
* ~ sudo su - root
* type your password
* You're root!
* # passwd
* create a password for root.
* Log off
* Log on as root.  Yes.

1.  Add LDAPv3 Directory access
* Open Directory Access from /Applications/Utilities or under System Preferences > Users & Groups.

* Click the Lock on the bottom of the window.

* Click on LDAPv3 then click Configure

* Select Options then click Add
    Enter a configuration name; e.g. myldap
    Server Name: LDAP server canonical dns or IP address; e.g. myldap.my.com
    Click on LDAP Mappings and select RFC 2307 (Unix)
    For search base, put in your LDAP search base; e.g.  dc=my,dc=com
    Don not Check SSL

* Click edit and make sure all settings are at either their default or match your environment
    Under Search and Mappings, if you're using a stock OpenLDAP install, it is safe to have a "Search in" 
all subtrees set.  This is recommended.
    Check all Record types and attributes.
    When done, Save Template.  Somewhere.
    Click OK, and OK again.

* At the Directory Access windows, Go to "Search Policy" and click on Authentication.
    You're now going to add a Directory domain.
    Select Custom Path

2.  
    Add the LDAPv3 server you just added.  Click the + and add /LDAPv3/Server Name
    Keep /Local/Default at the top; if not you'll not be able to logon with a local user account.
    Once done, test your LDAP configuration by going to Directory Editor (also in Directory Access).  
In the search box, search for a known account.

Did you mess up?

Check, /var/log/system.log for -14002 errors.

1.  Remove all contents of directory /Library/Preferences/DirectoryService
2.  Open /Applications/Utilities/Netinfo Manager and remove contents of directory /config/mcx-mask

If not, time to allow logons.

There's a bug in OSX 10.7.2 not allowing LDAP users to logon.  Nice.  Let's fix that.

1.  As root...
# ldapsearch -x -h myldap.my.com -b "" -s base "(objectclass=*)" supportedSASLMechanisms

You should see something akin to:
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5

This shows you the sort of authentication mechanisms your LDAP server supports.  
Let's make OSX add the SASL mechanisms - even if your LDAP server isn't using them.

2.  Open the Opendirectoryd plist for your LDAPv3 server in /Library/Preferences/OpenDirectory/Configurations/LDAPv3, 
and add all of the advertised SASL garnered from above to the Denied SASL Methods array in the plist file.  Simply browse 
to the file, double click and use xcode to edit.

Add the items here:
module options > ldap > Denied SASL Methods
add string items.  Add the strings exactly as provided by your LDAP server.

3.  Reboot the OSX machine and you'll then be able to logon using a LDAP-defined user.

likewise & netapp lessons learned

just so that i remember, here're some unsanitized notes.

the environment:
a mess of linux boxes, a group of windows systems and a netapp.  active directory is the backend authentication mechanism.

the end goal:
authenticate linux/macos users to active directory and access home directories on the netapp.

likewise...
install likewise however you'd like. then...
afterward:
/opt/likewise/bin/lwconfig --detail AssumeDefaultDomain 
/opt/likewise/bin/lwconfig AssumeDefaultDomain true 
/opt/likewise/bin/lwconfig --show AssumeDefaultDomain 
/opt/likewise/bin/lwconfig LoginShellTemplate /bin/bash

/opt/likewise/bin/lwconfig --show HomeDirTemplate 
/opt/likewise/bin/lwconfig HomeDirPrefix /home 
/opt/likewise/bin/lwconfig HomeDirTemplate %H/%U 
/opt/likewise/bin/lwconfig CreateHomeDir false

in /etc/group:
admin:x:115:DOMAIN\me

in /etc/sudoers:
DOMAIN\\domain^admins ALL=(ALL) ALL

netapp...
netapp must have following:
qtree security /vol/silly_home unix

options cifs.signing.enable off
options cifs.nfs_root_ignore_acl on

passwd must have the uid of the windows user per likewise; e.g.
me::1952501801:1952501801::/:

* check using wcc -a & wcc -u
if not set, then user will be mapped to pcuser and unable to use nfs share.
UNIX uid = 65534

in usermap.cfg have a domain admin mapped as unix root:
DOMAIN\me <= root

nfs export must be long, not truncated; e.g.:
/vol/silly_home  -sec=sys,rw

client machine must mount long nfs export:
netapp:/vol/silly_home /home      nfs         defaults        0 0

problems with cifs?  turn on logging; shows up on the console.
options cifs.trace_login on

OSX 10.7.2 addendum

Since /Users is probably in use by local accounts, it would be best to mount 
the export to the place specified above (in our case /home).
OSX 10.7.2 does not have fstab.  Here's what you do:

Become root.
~ sudo su - root
As root...
# touch /etc/fstab
# vi /etc/fstab
Add the following:
netapp:/vol/silly_home /home      nfs         auto        0 0
# mount -a
Voila.