[Freeipa-users] Solaris 10 client configuration using profile

Wed Oct 15 16:31:22 UTC 2014

Thank you both. I successfully set up a new profile on the server and am able to use it with authentication. It seems to work for existing users but I am having issues when I add new user access via HBAC so I am trying to figure that part out. There are a few options I can invoke using ldapclient manual that I cannot seem to add to the profile (mainly attributeMap settings) but I don't think that is the issue. I will plug away at it more tomorrow and see if I can figure it out.

-----Original Message-----
From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Sigbjorn Lie
Sent: Saturday, October 11, 2014 11:26 AM
To: Alexander Bokovoy
Cc: sipazzo; Freeipa-users at redhat.com
Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile

On Sat, October 11, 2014 19:54, Alexander Bokovoy wrote:
> On Sat, 11 Oct 2014, Rob Crittenden wrote:
>
>> sipazzo wrote:
>>> Thank you,I know where the profile is in the directory tree and how 
>>> I would invoke it were it there...I don't know how to get it into 
>>> the directory tree so that it is available to clients. I see posts 
>>> giving examples of different profilesthat could be used but no post as to how to add it to the directory. Sorry if I am missing something obvious.
>>>
>>>
>>> --------------------------------------------
>>> On Fri, 10/10/14, Rob Crittenden <rcritten at redhat.com> wrote:
>>>
>>>
>>> Subject: Re: [Freeipa-users] Solaris 10 client configuration using 
>>> profile
>>> To: "sipazzo" <sipazzo at yahoo.com>, freeipa-users at redhat.com
>>> Date: Friday, October 10, 2014, 4:53 PM
>>>
>>>
>>> sipazzo wrote:
>>>>
>>> Hello, I am trying to set up a default profile for my Solaris 10 IPA 
>>> clients as recommended. I generated a profile on a Solaris with the 
>>> attributes I needed except I got an "invalid parameter" error when 
>>> specifying the domainName attribute like this -a 
>>> domainName=example.com even though this parameter works when I use 
>>> it in ldapclient manual. More of an issue though is I have been 
>>> unable to find documentation on getting the profile incorporated 
>>> into the ipa server. How do I get this profile on the ipa server and 
>>> make it available to my Solaris clients? Also, my understanding is 
>>> the clients periodically check this profile so they stay updated with the latest configuration information. What generates this check? Is it time based, a restart of a service or ??
>>>>
>>>> Thank you for any
>>>>
>>> assistance.
>>>>
>>>
>>> It's been forever since I configured a Solaris anything client but I 
>>> can tell you where the profile gets stored: 
>>> cn=profilename,cn=default,ou=profile,$SUFFIX
>>>
>>> IPA ships with a default
>>> profile of:
>>>
>>> dn:
>>> cn=default,ou=profile,$SUFFIX ObjectClass:
>>> top ObjectClass: DUAConfigProfile
>>> defaultServerList: $FQDN
>>> defaultSearchBase: $SUFFIX
>>> authenticationMethod: none
>>> searchTimeLimit: 15
>>> cn:
>>> default serviceSearchDescriptor:
>>> passwd:cn=users,cn=accounts,$SUFFIX
>>> serviceSearchDescriptor:
>>> group:cn=groups,cn=compat,$SUFFIX
>>> bindTimeLimit: 5
>>> objectClassMap:
>>> shadow:shadowAccount=posixAccount
>>> followReferrals:TRUE
>>>
>>>
>>> The full schema can be found at
>>> http://docs.oracle.com/cd/E23824_01/html/821-1455/schemas-17.html
>>>
>>>
>>> So if your profile is named
>>> foo you'd invoke it with something like:
>>>
>>> # ldapclient init -a
>>> profileName=foo ipa.example.com
>>>
>>> rob
>>>
>>>
>>
>> Here is an example inspired by
>> https://bugzilla.redhat.com/show_bug.cgi?id=815515
>>
>>
>> $ ldapmodify -x -D 'cn=Directory Manager' -W
>> dn: cn=solaris_authssl_test,ou=profile,dc=example,dc=com
>> objectClass: top
>> objectClass: DUAConfigProfile
>> cn: solaris_authssl_test
>> authenticationMethod: tls:simple
>> bindTimeLimit: 5
>> credentialLevel: proxy
>> defaultSearchBase: dc=example,dc=com
>> defaultSearchScope: one
>> defaultServerList: ipa01.example.com ipa02.example.com 
>> ipa03.example.com
>> followReferrals: TRUE
>> objectclassMap: shadow:shadowAccount=posixAccount
>> objectclassMap: printers:sunPrinter=printerService
>> preferredServerList: ipa01.example.com ipa02.example.com
>> profileTTL: 6000
>> searchTimeLimit: 10
>> serviceSearchDescriptor: 
>> passwd:cn=users,cn=accounts,dc=example,dc=com
>> serviceSearchDescriptor: group:cn=groups,cn=compat,dc=example,dc=com
>> serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=example,dc=com
>> serviceSearchDescriptor: 
>> ethers:cn=computers,cn=accounts,dc=example,dc=com
>> serviceSearchDescriptor: 
>> automount:cn=default,cn=automount,dc=example,dc=com
>> serviceSearchDescriptor:
>> auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=e
>> xample,dc=com
>> serviceSearchDescriptor: aliases:ou=aliases,ou=test,dc=example,dc=com
>> serviceSearchDescriptor: 
>> printers:ou=printers,ou=test,dc=example,dc=com
>> <blank line>
>> ^D
>>
>>
>> You may want to check out
>> https://bugzilla.redhat.com/show_bug.cgi?id=815533 as well.
>>
> Should the profile be available anonymously? It is not in 4.x:
> $ ldapsearch -x -b ou=profile,dc=ipacloud,dc=test # extended LDIF # # 
> LDAPv3 # base <ou=profile,dc=ipacloud,dc=test> with scope subtree # 
> filter: (objectclass=*) # requesting: ALL #
>
>
> # search result
> search: 2
> result: 0 Success
>
>
> # numResponses: 1
> $ kinit admin
> Password for admin at IPACLOUD.TEST:
> $ ldapsearch -Y GSSAPI -b ou=profile,dc=ipacloud,dc=test SASL/GSSAPI 
> authentication started SASL username: admin at IPACLOUD.TEST SASL SSF: 56 
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base <ou=profile,dc=ipacloud,dc=test> with scope subtree # filter: 
> (objectclass=*) # requesting: ALL #
>
>
> # profile, ipacloud.test
> dn: ou=profile,dc=ipacloud,dc=test
> objectClass: top
> objectClass: organizationalUnit
> ou: profiles
> ou: profile
>
>
> # default, profile, ipacloud.test
> dn: cn=default,ou=profile,dc=ipacloud,dc=test
> defaultServerList: cc21.ipacloud.test
> defaultSearchBase: dc=ipacloud,dc=test
> objectClass: top
> objectClass: DUAConfigProfile
> serviceSearchDescriptor: 
> passwd:cn=users,cn=accounts,dc=ipacloud,dc=test
> serviceSearchDescriptor: group:cn=groups,cn=compat,dc=ipacloud,dc=test
> searchTimeLimit: 15
> followReferrals: TRUE
> objectclassMap: shadow:shadowAccount=posixAccount
> bindTimeLimit: 5
> authenticationMethod: none
> cn: default
>
>
> # search result
> search: 4
> result: 0 Success
>
>
> # numResponses: 3
> # numEntries: 2
>
>
>
> I think it should be available anonymously too, so we need to add a 
> specialized ACI for that. --

Hi,

The DUA profile does not need to be available anonymously. Additional parameters (-D to specify a ldap user DN and -w or -W for password for the ldap user, if memory serves correctly) can be specified to allow the ldapclient script to bind to the LDAP server before looking for a DUA profile. The ldapclient script had an issue in earlier Solaris 10, which prevented the additional bind parameters from working, however later patches (released a few years ago now) has solved this issue.

I´ve also configured Solaris 8 with the IPA LDAP server being closed for anonymous connections, and it works just fine.

I do however use the "rootdse" option when closing the LDAP server for anonymous connections. If I remember correctly this has to be done to make the Solaris "ldapclient" script to work.

For the bugzillas referred to by Rob, these are the instructions I wrote after I completed migration of several environments having Solaris 10 (and some Solaris 8) from a NIS environment to an IPA environment, and these DUA profiles are in production today and working just fine.

Regards,
Siggi

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project