sundeep dhall wrote:


In the doc, "ldapclient" is used to setup the solaris server as an ldap client (to AD) The cmd includes the basic setup (lines 1-6) + attribute mapping (remaining lines)

dsee% ldapclient -v manual \
-a credentialLevel=self \
-a authenticationMethod=sasl/gssapi \
-a defaultSearchBase=dc=companyxyz,dc=com \
-a \
-a defaultServerList= \
-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=companyxyz,dc=com?one \
-a serviceSearchDescriptor=group:cn=users,dc=companyxyz,dc=com?one

During the kclient setup, an object representing the opensolaris client is put into the cn=computers container.

Is it possible to centrally maintain the attribute map in the server and use it from there, rather than define and use it locally, as in the above example
- Is this what a "profile" is meant for ?
- do I stuff in the additional params (as above) into a profile that I store in AD ?

I believe so, but I know exactly zero about how to do that.

# *ldapclient genprofile \*
***-a* *profileName=myprofile \*
***-a* *defaultSearchBase=dc=west,dc=example,dc=com \*
***-a* *"defaultServerList=" \*
*> myprofile.ldif*
# *ldapadd* *-h* ** *-D* *“cn=directory manager”* *-f* *myprofile.ldif*

# *ldapclient init \*
*-a profileName=myprofile \*

Is idmap primarily used to map exisiting users in Solaris with those in AD ?
and does it do "ephemeral mapping" for users that don't exist in solaris.

Yes, but... once you have set AD up as your UNIX name service, those users *do* exist "in" Solaris, or at least the users in your local domain do.

In that environment, idmap's purpose is to associate the Windows identity with the UNIX identity. As humans, we know that there's only one record there and that we're seeing the same identity from Windows and UNIX. The software doesn't know that; it assumes that the identities that it sees through Windows-like mechanisms are distinct from the identities that it sees through UNIX-like mechanisms. Idmap ties the two together.

Idmap will also do ephemeral mapping for those identities that do not have usable IDMU data, either because the IDMU data is not populated or because the user is from a different domain.

For my initial attempt I would create new users in AD only.

If you've set up AD as your UNIX name service and you populate the IDMU data on those users, they *are* Solaris users. There is no need to create them in any other name service.


On 05/19/10 04:29 PM, Jordan Brown wrote:
sundeep dhall wrote:

Is this the appropriate alias for the question below.

Not really. We know a fair amount about the subject, and might well be the company experts on Active Directory, but we're not the authorities on either LDAP or Kerberos.

Here's an article that describes how to do what you're looking for:

Actually, a note: I expect that that setup only works for users in one domain. I would not expect you to be able to log in using n...@domain style names.

Else, can I be pointed to the correct group for help on naming service and setup of solaris as an ldap client to Active Directory

- demonstrate opensolaris interop with AD.
-- user login via console, via SSH
- All users in AD
- kerberos for authentication
- attribute retrieval, password policy enforcement

- I have kerberos configuration of my solaris server working against AD (using kclient)
Name services.
- I can retrieve some attributes using
- getent passwd
- I've set this up to use kerberos for login, but this is not working
login    auth required
login    auth sufficient  

Q) Do I need to setup "ldapclient" for this to work ?

thank you

On 05/13/10 11:01 AM, Jordan Brown wrote:
sundeep dhall wrote:

I checked with my customer on this.
It seems they are interested in being able to delegate authentication to the solaris server to AD using kerberos and on the solaris server, they have scripts that would query the uid, primary gid, secondary gid for the user.
and then execute using those permissions.

I am not sure that I fully understand the customer's needs, but it seems like they're reinventing our existing LDAP and Kerberos infrastructure.

If you just want to be able to log in using account information stored in AD, you don't have to write any scripts. You just have to configure your AD correctly (with IDMU) and set up LDAP and Kerberos on the Solaris system. That's not as easy as it should be, but it can be done.

Today they use SAMBA to achieve the authentication portion.

They do not need access to samba-like shares on the solaris server

Is this narrow requirement set possible in the current implementation using b134 ? - If so, would I only need to use the "kclient" script to setup the authentication to AD ?


On 5/11/2010 5:21 PM, Afshin Salek wrote:


On 05/11/10 02:54 PM, sundeep dhall wrote:

I am coming to grips with the various terms, so please bear with me.

What I want to currently prototype is the following:-
- osol server authentication using kerberos against AD. User repo only
on AD
- retrieval of user and group attributes from AD.
-- ie getent or other similar calls on solaris would give me the uid,
gid set on AD
- password resets done on AD would be reflected on the osol side when
the user attempts to authenticate.

It seems that this setup was originally done using a script called
ADjoin (now deprecated) and is now done vis kclient
Q) Does this much work today ? either in 2009.06 or later ?

I am presuming that what you describe as not currently supported is the
- AD is domain controller and is used for authentication
- OpenSolaris server is a CIFS (SMB) server operating in domain mode

Yes, that is what I'm referring to. So I'm not sure what you are
referring to as "osol server authentication using kerberos against AD". Is there any SMB file access involved here in your prototype? What kind of access to Osol are you trying to authenticate against AD using Kerberos?

If that is so, then I presume that the CIFS capability works today in
workgroup mode where users repository is on the osol side.

There is no AD or kerberos is involved in workgroup mode. SMB server
performs the authentication against the local /var/smb/smbpasswd


Please validate

thank you

On 05/11/10 04:37 PM, Afshin Salek wrote:
Kerberos authentication for SMB users connecting to Solaris SMB server
is under development, so it's not currently supported.


On 05/11/10 02:27 PM, sundeep dhall wrote:
Hi Alan,

Thank you for the flag.
I am downloading b134 from

I have setup AD on Win2008r2 as well as DNS

The intent is to show that users will be created in AD
Once osol is integrated with the AD as a kerberos client for
authentication, users will be able to login into osol via their auth
to AD.

I have skimmed through the docs on setting up kerberos client for AD

Q1)I am presuming that perhaps prior to this, the only step required on
the osol side would be to
setup nsswitch.conf and resolv.conf.

Is that correct ?

Q2) How does the CIFS setup on domain-mode work in conjunction to the
above methodology ?

Is that a 2ndary step I could do to show CIFS file sharing, or do the
latter steps call kclient internally ?

thank you

On 05/11/10 03:20 PM, Alan Wright wrote:
On 05/11/10 08:34 AM, sundeep dhall wrote:

Intent is to demonstrate OpenSolaris2009.06 authentication with AD on
Win2008r2 and UID, GID access based on user creation in AD

For use with Windows, it would be better to upgrade to something
more recent than OpenSolaris 2009.06. The SMB support in 2009.06
is broken.


I am reading up on the following for kclient

But my question is more on the AD side.
I have setup AD on the demo machine.

Q) In 2003, there was a SFU that enabled the AD to have the schema
for unix
Is a similar setting required for 2008 ?
Pointers to where this needs to be done would be appreciated.

thank you

cifs-discuss mailing list

cifs-discuss mailing list

cifs-discuss mailing list

cifs-discuss mailing list

cifs-discuss mailing list

Reply via email to