Forgot to post this earlier. Here are my personal notes for getting
auth to AD working:
(1) Add hostname/IP in DHCP (if applicable) and DNS
(2) Configure NTP on host (need /etc/inet/ntp.conf, copy from
/etc/inet/ntp.client)
(3) pkg install pkg:/system/security/kerberos-5
(4) kclient
(5) Enable stuff
sudo svcadm enable svc:/network/dns/client:default
sudo svcadm enable name-service-cache
sudo svcs -a name-service-cache
(6) Modify /etc/nsswitch.ldap
-bash-4.0$ grep dns /etc/nsswitch.ldap
hosts: dns files
ipnodes: dns files
(7) LDAP client config:
sudo ldapclient -v manual -a credentialLevel=self -a
authenticationMethod=sasl/gssapi -a defaultSearchBase=dc=foo,dc=com
-a domainName=foo.com -a defaultServerList=1.2.3.4 -a
attributeMap=passwd:gecos=cn -a
attributeMap=passwd:homedirectory=unixHomeDirectory -a
objectClassMap=group:posixGroup=group -a
objectClassMap=passwd:posixAccount=user -a
objectClassMap=shadow:shadowAccount=user -a
serviceSearchDescriptor=passwd:cn=users,dc=foo,dc=com?one -a
serviceSearchDescriptor=group:cn=users,dc=foo,dc=com?one
sudo svcadm restart svc:/network/ldap/client:default
foo.com is the domain
1.2.3.4 is an AD server
(8) Edit /etc/pam.conf to look like this
#
#
# Copyright 2010 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# PAM configuration
#
# Unless explicitly defined, all services use the modules
# defined in the "other" section.
#
# Modules are defined with relative pathnames, i.e., they are
# relative to /usr/lib/security/$ISA. Absolute path names, as
# present in this file in previous releases are still acceptable.
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_cred.so.1
login auth sufficient pam_krb5.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth sufficient pam_krb5.so.1
other auth required pam_unix_auth.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other account requisite pam_roles.so.1
other account required pam_unix_account.so.1
other account required pam_krb5.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session management
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
#
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
On Mon, Mar 7, 2011 at 10:14 AM, Roy Sigurd Karlsbakk <r...@karlsbakk.net>
wrote:
>> > - I want to allow users to login to servers on S10, Linux and OI
>> > using their AD accounts, but this doesn't seem to work. I can't
>> > find any AD PAM module, and I didn't have much luck with SMB. The
>> > docs said passwd should create compatible passwords after a change,
>> > but passwd didn't let me do much:
>>
>> The integration is not that complete on *solaris.
>> With an AD account, you can connect via the SMB service, but not login
>> locally.
>
> Are you sure this isn't doable with the LDAP PAM support?
>
> Vennlige hilsener / Best regards
>
> roy
> --
> Roy Sigurd Karlsbakk
> (+47) 97542685
> r...@karlsbakk.net
> http://blogg.karlsbakk.net/
> --
> I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det
> er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av
> idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og
> relevante synonymer på norsk.
>
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
