I was wondering if the Fedora Directory Server supports Windows clients? I didn't see anything on the site about it. Sorry if it's there and I just missed it.
I can't seem to get fds to work. I have CentOS 4.1 installed and working
fine. FDS appears to have installed fine as well. When I run the admin
server as a non-root user no messages appear, and when I try and telnet to
port 389 it says connection is refused, meaning the admin server isn't
running at all. When I try startconsole I get the following as a non-root
user:
Console: Can't connect to X11 window server using ':0.0' as the value of the
DISPLAY variable.
When I run start-admin as root I get the following message:
warning: daemon is running as super-user
[LS ls1] http://node.internal-datacom.com, port 40795 ready to accept
requests
But this doesn't stay. It appears that the admin server doesn't remain
running, maybe 5-10 seconds. Is there any way to fix this timeout problem so
that admin server remains running?
_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger 7.0 today!
http://messenger.msn.co.uk
I dug through the RFCs. It appears the aRecord attribute was defined
first as stated in RFC1274 (1991). Remember, these are all X.500 RFCs.
Shortly thereafter, RFC1279 (1991) came out defining dNSRecord, as the
preferred method for storing DNS attributes in X.500, but failed to
recommend an OID. Years later, an internet draft recommendation
draft-ietf-asid-ldap-domains-01 (1997) recommended the dNSRecord
attribute use the same OID as aRecord. This appears to be what Netscape
has adopted and incorrectly attributed to 'Internet directory pilot'
(RFC 1274). To add to the confusion, the schema this attribute is stored
in hints towards RFC 2247, which bears no mention of dNSRecord or the
draft recommendation.
Also note that the 28pilot.ldif schema contains the following statement:
#
# Schema from the pilot RFCs, especially RFC 1274, that is no longer
# recommended by Netscape for use in new deployments. Please be aware
# that future RFCs that succeed RFC 1274 may deprecate some or all of
# these attribute types and classes.
#
This appears to not be the case according to RFC 3383 (2002 - current
best practices for LDAP) where aRecord is mentioned and dNSRecord is
not. So, one must assume that Netscape was in error since dNSRecord
never made it into any RFC. Perhaps it should be fixed in the schema?
s/dNSRecord/aRecord and move it to 28pilot.ldif? Perhaps keeping
dNSRecord as an alias for compatability purposes.
CC'ing the FDS list for any thoughts.
Dan-
Daniel Williams wrote:
> It's really the old Netscape/iPlanet DS, which uses the " Netscape
> RFC1274 " to define how domain names are stored in LDAP.
> Take a look at this
> http://devel.it.su.se/cgi-bin/local/cvsweb.cgi/sukat-schema/pilot.schema?re…
>
> But any way, I added the aRecord attribute to the dNSRecord and every
> thing works fine, nice...
>
> Also, I setup a BIND 9.3.x flat file slave from the BIND 9.3 LDAP
> server and every thing work great there as well.
>
> Thanks Dan for your help.....
>
> -Daniel
>
> venaas(a)ivanova.venaas.no wrote:
>
>> On Thu, Jul 14, 2005 at 09:16:00PM -0500, Dan Cox wrote:
>>
>>
>>> Yes, I've done the conversion. The problem is the dnszone schema is
>>> based on a deprecated RFC. The immediate conflict is with the
>>> aRecord attribute, which uses the OID of the newer RFC spec
>>> attribute dNSRecord.
>>>
>>
>>
>> So the problem is that dnszone uses the same attribute name but a
>> different OID? Not sure I understood this correctly. What is their
>> syntax for aRecord, and where is it defined? It should not be a
>> problem using their aRecord definition if the syntax can hold the
>> necessary information.
>>
>> RFC 1274 says:
>>
>> 9.3.22. DNS ARecord
>>
>> The A Record attribute type specifies a type A (Address) DNS
>> resource
>> record [6] [7].
>>
>> aRecord ATTRIBUTE
>> WITH ATTRIBUTE-SYNTAX
>> DNSRecordSyntax
>> ::= {pilotAttributeType 26}
>>
>> and
>>
>> DNSRecordSyntax ATTRIBUTE-SYNTAX
>> IA5String
>> MATCHES FOR EQUALITY
>>
>> and this should be fine. Have they somehow managed to break with this?
>>
>> So what is the FDS server? Is it really Netscape/iPlanet or something
>> else?
>>
>> Stig
>>
>>
>>
>>> Here is the workaround:
>>> 1. convert the dnszone.schema to FDS format using the conversion
>>> script on the web site.
>>> 2. save it to something like 99dns.ldif in
>>> /opt/fedora-ds/slapd-*/config/schema/ directory.
>>> 3. edit 99dns.ldif and completely remove the aRecord attribute line.
>>> 4. edit 05rfc2247.ldif, find the dNSRecord attribute line and change
>>> it to this:
>>> attributeTypes: ( 0.9.2342.19200300.100.1.26 NAME ( 'aRecord'
>>> 'dNSRecord' )DESC 'Pilot attribute type' SYNTAX
>>> 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'Internet directory pilot' )
>>>
>>> So we've basically tacked on the aRecord as an attribute alias name.
>>> Note the aRecord is actually the primary name, making dNSRecord the
>>> alias. This is important because if this is reversed, then it will
>>> not work due to the way the LDAP server is queried. This IS a hack,
>>> since the the format of the aRecord is not the same as dNSRecord in
>>> the RFCs; however the directory server doesn't enforce the syntax
>>> rules. So this shouldn't be a problem unless you use some other
>>> services which rely on valid dNSRecord attribute syntax.
>>>
>>> I've seen a pretty good performance boost since moving from OpenLDAP
>>> to FDS. I'm curious if others see the same results.
>>>
>>> Dan-
>>>
>>> Daniel Williams wrote:
>>>
>>>
>>>
>>>> Hello,
>>>> Has anyone tried this?
>>>>
>>>> I'm working on getting the dNSZone moved over but the " Netscape "
>>>> -- uses the same OID.
>>>>
>>>> Thanks up front.
>>>>
>>>> -Daniel
>>>> _______________________________________________
>>>> Dns-ldap mailing list
>>>> Dns-ldap(a)uninett.no
>>>> http://tyholt.uninett.no/mailman/listinfo/dns-ldap
>>>>
>>>
>>> _______________________________________________
>>> Dns-ldap mailing list
>>> Dns-ldap(a)uninett.no
>>> http://tyholt.uninett.no/mailman/listinfo/dns-ldap
>>>
>>>
>>
>>
>>
>>
>
> _______________________________________________
> Dns-ldap mailing list
> Dns-ldap(a)uninett.no
> http://tyholt.uninett.no/mailman/listinfo/dns-ldap
Hi all,
I would like to know what implementation of Kerberos is prefered to
setup SASL/GESSAPI with Fedora DS: MIT or Heimdal?
Thanks for your comments.
Sam
Hi all,
I've put the beginnings of a Solaris client setup doc on the wiki. As
questions come up, I or others can update the document. If you're
missing schemas or having some issues, have a look.
http://directory.fedora.redhat.com/wiki/Howto:SolarisClient
brian
Thanks George and Rich for correcting me, now I understand why there seems to be some "extra" stuffs there in 99user.ldif like the many "aci:" lines and so forth.
DUAConfigProfile.schema + solaris.schema != 99user.ldif
DUAConfigProfile.schema + solaris.schema ~= 61duaconfigprofile.ldif + 61solaris.ldif
Rgds
Gary
-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com on behalf of Rich Megginson
Sent: Sat 7/16/2005 2:08 AM
To: General discussion list for the Fedora Directory server project.
Cc:
Subject: Re: [Fedora-directory-users] Solaris Native LDAP Client against FDS7.1Server
George Holbert wrote:
>>
>>
>> So if there is an existing Solaris8/9 DS5.2 server, simply copy
>> 99user.ldif from DS5.2 over to FDS7.1.
>>
>
> One caution about this: 99user.ldif stores ALL schema changes you
> make to the directory server via ldapmodify. This is not necessarily
> just DUAConfigProfile and other Solaris client schema updates.
>
>> DUAConfigProfile.schema + solaris.schema = 99user.ldif
>>
> This is true if you install a fresh SunDS 5.2 or FDS 7.1 directory
> server, and then add the schema changes in DUAConfigProfile.schema and
> solaris.schema via ldapmodify. Sun's favorite way of making these
> changes is the Solaris script: /usr/lib/ldap/idsconfig
Right. So you could just use this script
http://www.directory.fedora.redhat.com/download/ol-schema-migrate.pl
and do perl ol-schema-migrate.pl DUAConfigProfile.schema >
slapd-foo/config/schema/61duaconfigprofile.ldif
and
perl ol-schema-migrate.pl solaris.schema >
slapd-foo/config/schema/61solaris.ldif
>
>
>
> Tay, Gary wrote:
>
>> IIRC the two .schema files in my OpenLDAP HOW-TO is actually equivalent
>> to the 99user.ldif (residing in
>> $LDAP_ROOT/slapd-`hostname`/config/schema) file provided by SUN ONE
>> DS5.2, i.e.
>>
>> DUAConfigProfile.schema + solaris.schema = 99user.ldif.
>>
>> So if there is an existing Solaris8/9 DS5.2 server, simply copy
>> 99user.ldif from DS5.2 over to FDS7.1.
>>
>> Someone who is using Oracle Internet Directory had asked me in
>> supportforum.sun.com how to configure Solaris Native LDAP Client to
>> authenticate against OID, I had some brief instructions given there, I
>> reproduced and modified a bit as a quick notes here.
>>
>> PLEASE NOTE that I haven't tried these steps but believe it should work
>> as FDS7.1 is similar to DS5.2, anyone has tried these please feel free
>> to comment and add.
>>
>> ===
>> To make a Solaris Native LDAP Clients (Solaris8 or Solaris9) worked
>> against FDS7.1 Server, you would have to do a little hackings to make
>> FDS7.1 Server acts like a SUN DS5.2 ldapclient profile(s) provider,
>> described as in the following notes,
>>
>> - Add "nisDomain" to rootDN object (eg: object is dc=example,dc=com) so
>> that "ldapclient" will be able to find this nisDomainObject, using
>> ldapmodify or GUI based tools.
>>
>> objectClass: nisDomainObject
>> nisDomain: example.com
>>
>> - Copy schema 99user.ldif from DS5.2 to FDS7.1
>>
>> - Create ou=profile OU object and add cn=ProxyAgent as a proxy
>> credentials proxy user under it
>>
>> - Create "default" or "customized" ldapclient profile(s) under the
>> ou=profile subtree for simple bind or simple bind + TLS or whatever,
>> using manually prepared ldif file or ldif generated by "ldapclient
>> genprofile" command, read "man ldapclient" for more details.
>>
>> - Setup two ACLs under dc=example,dc=com object, ACL1 should appear
>> before ACL2, they are actually present in any typical SUN ONE DS5.2
>>
>> 1. LDAP_Naming_Services_deny_write_access
>> (targetattr =
>> "cn||uid||uidNumber||gidNumber||homeDirectory||shadowLastChange||shadowM
>> in||shadowMax||shadowWarning||shadowInactive||shadowExpire||shadowFlag||
>> memberUid")(version 3.0; acl LDAP_Naming_Services_deny_write_access;
>> deny (write) userdn = "ldap:///self";)
>>
>> 2.LDAP_Naming_Services_proxy_password_read
>> (target="ldap:///dc=example,dc=com")(targetattr="userPassword")(version
>> 3.0; acl LDAP_Naming_Services_proxy_password_read; allow
>> (compare,read,search) userdn =
>> "ldap:///cn=proxyagent,ou=profile,dc=example,dc=com";)
>>
>> Tips: delete the word "read" if you do not want "ldaplist -l passwd" to
>> list userPassword(s), i.e. it becomes:
>>
>> (target="ldap:///dc=example,dc=com")(targetattr="userPassword")(version
>> 3.0; acl LDAP_Naming_Services_proxy_password_read; allow
>> (compare,search) userdn =
>> "ldap:///cn=proxyagent,ou=profile,dc=example,dc=com";)
>>
>> - It is advisable to set password hash scheme to CRYPT in FDS7.1.
>>
>> - It is advisable to add "shadowAccount" objectclass to your user
>> entries, on top of "posixAccount".
>>
>> - Note that Solaris "ldapclient" has an irritating act that it will
>> reset the "hosts:" entry to "hosts: files ldap" or something that puts
>> "ldap" in front of "dns", this should be adjusted back to "hosts: files
>> dns", otherwise something like telnet/ftp/ssh will break on hostname
>> lookup as the hosts lookup using "ldap" goes recursive.
>>
>> Rgds
>> Gary
>>
>> -----Original Message-----
>> From: fedora-directory-users-bounces(a)redhat.com
>> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Rich
>> Megginson
>> Sent: Friday, July 15, 2005 3:21 AM
>> To: General discussion list for the Fedora Directory server project.
>> Subject: Re: [Fedora-directory-users] Solaris Client
>>
>>
>> Brian Martinez wrote:
>>
>>
>>
>>> George,
>>>
>>> That is correct, we are attempting to use the FDS7 as a central
>>> authentication system for Solaris 10 NSS Clients with a PAM backend.
>>>
>>> We believe that we are missing the proper schemas on the server
>>> (DUAConfigProfile and Solaris) to support the Solaris Clients. The
>>> ones on Tay's website seem to be in the wrong format (schema instead
>>> of ldif)...or we just dont know how to import them!
>>>
>>
>>
>> You can use this script
>> http://www.directory.fedora.redhat.com/download/ol-schema-migrate.pl
>> found on this page
>> http://directory.fedora.redhat.com/wiki/Howto:OpenLDAPMigration
>> to convert .schema files to .ldif schema files. e.g.
>> perl ol-schema-migrate.pl solaris.schema >
>> slapd-myhost/config/schema/61solaris.ldif
>> Then restart slapd
>>
>>
>>
>>> We have been scrounging his site for clues/ideas...developers on the
>>> client side are convinced the server is the issue...developers on
>>> the server side believe it is the client. My take is that we
>>> already have
>>>
>>
>>
>>
>>
>>> the server "most" of the way, because we are successfully
>>> authenticating Linux clients securely to the FDS7 server and we are
>>> missing some essential piece on the server side to solve the Solaris
>>> puzzle.
>>>
>>> If you have any further thoughts, ideas, or prayers...feel free to
>>> send them our way.
>>>
>>>
>>>
>>>> From: "George Holbert" <gholbert(a)broadcom.com>
>>>> Reply-To: "General discussion list for the Fedora Directory server
>>>> project." <fedora-directory-users(a)redhat.com>
>>>> To: "General discussion list for the Fedora Directory server
>>>> project." <fedora-directory-users(a)redhat.com>
>>>> Subject: Re: [Fedora-directory-users] Solaris Client
>>>> Date: Thu, 14 Jul 2005 11:08:06 -0700
>>>>
>>>> Hi Brian,
>>>>
>>>> By "Solaris Clients", I assume you mean Solaris naming service (for
>>>> passwd, group, etc.).
>>>>
>>>> The answer is yes. Any modern, properly configured LDAP server,
>>>> including Fedora DS, can support Solaris naming service. However,
>>>> getting the server "properly configured" can be tricky.
>>>>
>>>> However, since Sun's own directory server ("Sun Java Enterprise
>>>> System Directory Server") is so very similar to Fedora DS, much of
>>>> the same preparation methods and documentation regarding SunDS will
>>>> apply directly to Fedora DS.
>>>>
>>>> A good starting point would be Gary Tay's fine documentation at:
>>>> http://web.singnet.com.sg/~garyttt/
>>>>
>>>> Gary's docs were written around iPlanet/Sun DS, but as I mentioned,
>>>> pretty much all of this should also apply to Fedora DS.
>>>>
>>>> Good luck!
>>>> -- George
>>>>
>>>>
>>>> Brian Martinez wrote:
>>>>
>>>>
>>>>
>>>>> All,
>>>>>
>>>>> Does the Fedora DS support Solaris Clients? If so, where can I find
>>>>> information, schema examples, etc....
>>>>>
>>>>> Thanks in advance,
>>>>> Brian
>>>>>
>>>>>
>>>>> --
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users(a)redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users(a)redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
>>>
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>
>>
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>>
>>
>>
>
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
IIRC the two .schema files in my OpenLDAP HOW-TO is actually equivalent
to the 99user.ldif (residing in
$LDAP_ROOT/slapd-`hostname`/config/schema) file provided by SUN ONE
DS5.2, i.e.
DUAConfigProfile.schema + solaris.schema = 99user.ldif.
So if there is an existing Solaris8/9 DS5.2 server, simply copy
99user.ldif from DS5.2 over to FDS7.1.
Someone who is using Oracle Internet Directory had asked me in
supportforum.sun.com how to configure Solaris Native LDAP Client to
authenticate against OID, I had some brief instructions given there, I
reproduced and modified a bit as a quick notes here.
PLEASE NOTE that I haven't tried these steps but believe it should work
as FDS7.1 is similar to DS5.2, anyone has tried these please feel free
to comment and add.
===
To make a Solaris Native LDAP Clients (Solaris8 or Solaris9) worked
against FDS7.1 Server, you would have to do a little hackings to make
FDS7.1 Server acts like a SUN DS5.2 ldapclient profile(s) provider,
described as in the following notes,
- Add "nisDomain" to rootDN object (eg: object is dc=example,dc=com) so
that "ldapclient" will be able to find this nisDomainObject, using
ldapmodify or GUI based tools.
objectClass: nisDomainObject
nisDomain: example.com
- Copy schema 99user.ldif from DS5.2 to FDS7.1
- Create ou=profile OU object and add cn=ProxyAgent as a proxy
credentials proxy user under it
- Create "default" or "customized" ldapclient profile(s) under the
ou=profile subtree for simple bind or simple bind + TLS or whatever,
using manually prepared ldif file or ldif generated by "ldapclient
genprofile" command, read "man ldapclient" for more details.
- Setup two ACLs under dc=example,dc=com object, ACL1 should appear
before ACL2, they are actually present in any typical SUN ONE DS5.2
1. LDAP_Naming_Services_deny_write_access
(targetattr =
"cn||uid||uidNumber||gidNumber||homeDirectory||shadowLastChange||shadowM
in||shadowMax||shadowWarning||shadowInactive||shadowExpire||shadowFlag||
memberUid")(version 3.0; acl LDAP_Naming_Services_deny_write_access;
deny (write) userdn = "ldap:///self";)
2.LDAP_Naming_Services_proxy_password_read
(target="ldap:///dc=example,dc=com")(targetattr="userPassword")(version
3.0; acl LDAP_Naming_Services_proxy_password_read; allow
(compare,read,search) userdn =
"ldap:///cn=proxyagent,ou=profile,dc=example,dc=com";)
Tips: delete the word "read" if you do not want "ldaplist -l passwd" to
list userPassword(s), i.e. it becomes:
(target="ldap:///dc=example,dc=com")(targetattr="userPassword")(version
3.0; acl LDAP_Naming_Services_proxy_password_read; allow
(compare,search) userdn =
"ldap:///cn=proxyagent,ou=profile,dc=example,dc=com";)
- It is advisable to set password hash scheme to CRYPT in FDS7.1.
- It is advisable to add "shadowAccount" objectclass to your user
entries, on top of "posixAccount".
- Note that Solaris "ldapclient" has an irritating act that it will
reset the "hosts:" entry to "hosts: files ldap" or something that puts
"ldap" in front of "dns", this should be adjusted back to "hosts: files
dns", otherwise something like telnet/ftp/ssh will break on hostname
lookup as the hosts lookup using "ldap" goes recursive.
Rgds
Gary
-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Rich
Megginson
Sent: Friday, July 15, 2005 3:21 AM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] Solaris Client
Brian Martinez wrote:
> George,
>
> That is correct, we are attempting to use the FDS7 as a central
> authentication system for Solaris 10 NSS Clients with a PAM backend.
>
> We believe that we are missing the proper schemas on the server
> (DUAConfigProfile and Solaris) to support the Solaris Clients. The
> ones on Tay's website seem to be in the wrong format (schema instead
> of ldif)...or we just dont know how to import them!
You can use this script
http://www.directory.fedora.redhat.com/download/ol-schema-migrate.pl
found on this page
http://directory.fedora.redhat.com/wiki/Howto:OpenLDAPMigration
to convert .schema files to .ldif schema files. e.g.
perl ol-schema-migrate.pl solaris.schema >
slapd-myhost/config/schema/61solaris.ldif
Then restart slapd
>
> We have been scrounging his site for clues/ideas...developers on the
> client side are convinced the server is the issue...developers on the
> server side believe it is the client. My take is that we already have
> the server "most" of the way, because we are successfully
> authenticating Linux clients securely to the FDS7 server and we are
> missing some essential piece on the server side to solve the Solaris
> puzzle.
>
> If you have any further thoughts, ideas, or prayers...feel free to
> send them our way.
>
>> From: "George Holbert" <gholbert(a)broadcom.com>
>> Reply-To: "General discussion list for the Fedora Directory server
>> project." <fedora-directory-users(a)redhat.com>
>> To: "General discussion list for the Fedora Directory server
>> project." <fedora-directory-users(a)redhat.com>
>> Subject: Re: [Fedora-directory-users] Solaris Client
>> Date: Thu, 14 Jul 2005 11:08:06 -0700
>>
>> Hi Brian,
>>
>> By "Solaris Clients", I assume you mean Solaris naming service (for
>> passwd, group, etc.).
>>
>> The answer is yes. Any modern, properly configured LDAP server,
>> including Fedora DS, can support Solaris naming service. However,
>> getting the server "properly configured" can be tricky.
>>
>> However, since Sun's own directory server ("Sun Java Enterprise
>> System Directory Server") is so very similar to Fedora DS, much of
>> the same preparation methods and documentation regarding SunDS will
>> apply directly to Fedora DS.
>>
>> A good starting point would be Gary Tay's fine documentation at:
>> http://web.singnet.com.sg/~garyttt/
>>
>> Gary's docs were written around iPlanet/Sun DS, but as I mentioned,
>> pretty much all of this should also apply to Fedora DS.
>>
>> Good luck!
>> -- George
>>
>>
>> Brian Martinez wrote:
>>
>>> All,
>>>
>>> Does the Fedora DS support Solaris Clients? If so, where can I find
>>> information, schema examples, etc....
>>>
>>> Thanks in advance,
>>> Brian
>>>
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>
>>
>>
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
Sorry, one correction on the content of /var/ldap/ldap_client_cred.
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=example,dc=com
NS_LDAP_BINDPASSWD= {NS1}ecfa88f3a945c411
-----Original Message-----
From: Tay, Gary
Sent: Friday, July 15, 2005 7:53 PM
To: 'General discussion list for the Fedora Directory server project.'
Subject: RE: [Fedora-directory-users] Solaris Native LDAP Client
againstFDS7.1 Server
FDS folks,
I just tried my procedures on a Solaris8 Native LDAP Client, It works!!!
I forgot to mention ONE IMPORTANT point, APPLY the latest kernel and
LDAP patches prior to anything, otherwise some error in /etc/pam.conf
may render your LDAP client "un-loginable" due to unrecognizable
keywords/options/flags.
Solaris8: kernel patch + 108993
Solaris9: kernel patch + 112960
Solaris10: I don't know, I have not touched one such yet, check sunsolve
patches info.
Some modifications to 99user.ldif is done by me, I am not sure if they
are really needed, anyway I list them here as FYI:
I removed these lines from 99user.ldif
- modifiersName: cn=directory manager
- mModifyTimestamp: 20050427082543Z
- All "aci:" lines
- nsSchemaCSN: 429ddf1d000000000000
Note that after setting up 99user.ldif in
$LDAP_ROOT/slapd-`hostname`/config/schema directory, you have to restart
slapd to load the new schema definitions, as Rich have said earlier.
You may use this sample ldif to create proxyAgent and sample ldapclient
profiles.ldif, it assumes password of proxyAgent is "password", if you
want to use a different password for proxyAgent, you may use
/opt/fedora-ds/slapd-`hostname`/getpwenc to find the {CRYPT} hash, for
the {NS1} hash, there is a trick to get a generated on a Solaris8
machine, read my post at
http://forum.sun.com/thread.jspa?threadID=25436&tstart=0
# cat proxyAgent_and_sample_profiles.ldif
dn: ou=profile,dc=example,dc=com
ou: profile
objectClass: top
objectClass: organizationalUnit
dn: cn=proxyagent,ou=profile,dc=example,dc=com
cn: proxyagent
sn: proxyagent
objectClass: top
objectClass: person
userPassword: {CRYPT}l14aeXtphVSUg
dn: cn=default,ou=profile,dc=example,dc=com
objectClass: top
objectClass: DUAConfigProfile
defaultServerList: ldap1.example.com
defaultSearchBase: dc=example,dc=com
authenticationMethod: simple
followReferrals: TRUE
defaultSearchScope: one
searchTimeLimit: 30
profileTTL: 43200
cn: default
credentialLevel: proxy
bindTimeLimit: 2
dn: cn=tls_profile,ou=profile,dc=example,dc=com
objectClass: top
objectClass: DUAConfigProfile
defaultServerList: ldap1.example.com
defaultSearchBase: dc=example,dc=com
authenticationMethod: tls:simple
followReferrals: FALSE
defaultSearchScope: one
searchTimeLimit: 30
profileTTL: 43200
bindTimeLimit: 10
cn: tls_profile
credentialLevel: proxy
serviceSearchDescriptor: passwd: ou=People,dc=example,dc=com
serviceSearchDescriptor: group: ou=group,dc=example,dc=com
serviceSearchDescriptor: shadow: ou=People,dc=example,dc=com
FDS seems to check tightly on objectClasses, if I omit "objectClass:
top" from the profile definitions, it will complain that "objectClass:
DUAConfigProfile" is not a valid "attribute" during ldapadd.
This is the /var/ldap/ldap_client_file I used:
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= ldap1.example.com
NS_LDAP_SEARCH_BASEDN= dc=example,dc=com
NS_LDAP_AUTH= simple
NS_LDAP_SEARCH_REF= TRUE
NS_LDAP_SEARCH_SCOPE= one
NS_LDAP_SEARCH_TIME= 30
NS_LDAP_CACHETTL= 43200
NS_LDAP_PROFILE= default
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_BIND_TIME= 2
And /var/ldap/ldap_client_cred, it assumes proxyAgent password is
"password"
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=platts,dc=mhm,dc=mhc
NS_LDAP_BINDPASSWD= {NS1}ecfa88f3a945c411
Make sure you "chmod 400 /var/ldap/ldap_client_???"
Copy /etc/nsswitch.ldap to /etc/nsswitch.conf, edit nsswitch.conf and
make sure that these lines exist:
passwd: files ldap
group: files ldap
shadow: files ldap
hosts: files dns
Set Solaris LDAP domain name, this is a one time execution only
# echo "example.com" >/etc/defaultdomain
# domainname `cat /etc/defaultdomain`
Now try to refresh ldap_cachemgr and nscd
# /etc/init.d/ldap.client stop
# /etc/init.d/ldap.client start
# ps -ef | grep ldap
# /usr/lib/ldap/ldap_cachemgr -g
# /etc/init.d/nscd stop
# /etc/init.d/nscd start
# ps -ef | grep nscd
Note that I DID NOT EVEN BOTHER to run "ldapclient init ..." or
"ldapclient manual ...", if I DO run it, I have to press CTRL-C to break
it so it runs to completion.
IMPORTANT NOTE: One side effect of running "ldapclient" is that it
resets "hosts: files dns" in /etc/nsswitch.conf to "hosts: ldap files"
and this affects the DNS names lookup, it is always advisable to double
check the "hosts:" entry in /etc/nsswitch.conf and adjust it back to the
desired "files dns" setting.
I used the sample pam.conf from this URL with all "pam_unix_cred.so.1"
lines commenting out as they are meant for Solaris10, do not comment
them out if you are using Solaris10.
http://docs.sun.com/app/docs/doc/816-4556/6maort2te?a=view
Have funs and good lucks!
Rgds
Gary
-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Tay,
Gary
Sent: Friday, July 15, 2005 12:39 PM
To: General discussion list for the Fedora Directory server project.
Subject: **Caution-External**: RE: [Fedora-directory-users] Solaris
Native LDAP Client againstFDS7.1 Server
IIRC the two .schema files in my OpenLDAP HOW-TO is actually equivalent
to the 99user.ldif (residing in
$LDAP_ROOT/slapd-`hostname`/config/schema) file provided by SUN ONE
DS5.2, i.e.
DUAConfigProfile.schema + solaris.schema = 99user.ldif.
So if there is an existing Solaris8/9 DS5.2 server, simply copy
99user.ldif from DS5.2 over to FDS7.1.
Someone who is using Oracle Internet Directory had asked me in
supportforum.sun.com how to configure Solaris Native LDAP Client to
authenticate against OID, I had some brief instructions given there, I
reproduced and modified a bit as a quick notes here.
PLEASE NOTE that I haven't tried these steps but believe it should work
as FDS7.1 is similar to DS5.2, anyone has tried these please feel free
to comment and add.
===
To make a Solaris Native LDAP Clients (Solaris8 or Solaris9) worked
against FDS7.1 Server, you would have to do a little hackings to make
FDS7.1 Server acts like a SUN DS5.2 ldapclient profile(s) provider,
described as in the following notes,
- Add "nisDomain" to rootDN object (eg: object is dc=example,dc=com) so
that "ldapclient" will be able to find this nisDomainObject, using
ldapmodify or GUI based tools.
objectClass: nisDomainObject
nisDomain: example.com
- Copy schema 99user.ldif from DS5.2 to FDS7.1
- Create ou=profile OU object and add cn=ProxyAgent as a proxy
credentials proxy user under it
- Create "default" or "customized" ldapclient profile(s) under the
ou=profile subtree for simple bind or simple bind + TLS or whatever,
using manually prepared ldif file or ldif generated by "ldapclient
genprofile" command, read "man ldapclient" for more details.
- Setup two ACLs under dc=example,dc=com object, ACL1 should appear
before ACL2, they are actually present in any typical SUN ONE DS5.2
1. LDAP_Naming_Services_deny_write_access
(targetattr =
"cn||uid||uidNumber||gidNumber||homeDirectory||shadowLastChange||shadowM
in||shadowMax||shadowWarning||shadowInactive||shadowExpire||shadowFlag||
memberUid")(version 3.0; acl LDAP_Naming_Services_deny_write_access;
deny (write) userdn = "ldap:///self";)
2.LDAP_Naming_Services_proxy_password_read
(target="ldap:///dc=example,dc=com")(targetattr="userPassword")(version
3.0; acl LDAP_Naming_Services_proxy_password_read; allow
(compare,read,search) userdn =
"ldap:///cn=proxyagent,ou=profile,dc=example,dc=com";)
Tips: delete the word "read" if you do not want "ldaplist -l passwd" to
list userPassword(s), i.e. it becomes:
(target="ldap:///dc=example,dc=com")(targetattr="userPassword")(version
3.0; acl LDAP_Naming_Services_proxy_password_read; allow
(compare,search) userdn =
"ldap:///cn=proxyagent,ou=profile,dc=example,dc=com";)
- It is advisable to set password hash scheme to CRYPT in FDS7.1.
- It is advisable to add "shadowAccount" objectclass to your user
entries, on top of "posixAccount".
- Note that Solaris "ldapclient" has an irritating act that it will
reset the "hosts:" entry to "hosts: files ldap" or something that puts
"ldap" in front of "dns", this should be adjusted back to "hosts: files
dns", otherwise something like telnet/ftp/ssh will break on hostname
lookup as the hosts lookup using "ldap" goes recursive.
Rgds
Gary
-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Rich
Megginson
Sent: Friday, July 15, 2005 3:21 AM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] Solaris Client
Brian Martinez wrote:
> George,
>
> That is correct, we are attempting to use the FDS7 as a central
> authentication system for Solaris 10 NSS Clients with a PAM backend.
>
> We believe that we are missing the proper schemas on the server
> (DUAConfigProfile and Solaris) to support the Solaris Clients. The
> ones on Tay's website seem to be in the wrong format (schema instead
> of ldif)...or we just dont know how to import them!
You can use this script
http://www.directory.fedora.redhat.com/download/ol-schema-migrate.pl
found on this page
http://directory.fedora.redhat.com/wiki/Howto:OpenLDAPMigration
to convert .schema files to .ldif schema files. e.g.
perl ol-schema-migrate.pl solaris.schema >
slapd-myhost/config/schema/61solaris.ldif
Then restart slapd
>
> We have been scrounging his site for clues/ideas...developers on the
> client side are convinced the server is the issue...developers on the
> server side believe it is the client. My take is that we already have
> the server "most" of the way, because we are successfully
> authenticating Linux clients securely to the FDS7 server and we are
> missing some essential piece on the server side to solve the Solaris
> puzzle.
>
> If you have any further thoughts, ideas, or prayers...feel free to
> send them our way.
>
>> From: "George Holbert" <gholbert(a)broadcom.com>
>> Reply-To: "General discussion list for the Fedora Directory server
>> project." <fedora-directory-users(a)redhat.com>
>> To: "General discussion list for the Fedora Directory server
>> project." <fedora-directory-users(a)redhat.com>
>> Subject: Re: [Fedora-directory-users] Solaris Client
>> Date: Thu, 14 Jul 2005 11:08:06 -0700
>>
>> Hi Brian,
>>
>> By "Solaris Clients", I assume you mean Solaris naming service (for
>> passwd, group, etc.).
>>
>> The answer is yes. Any modern, properly configured LDAP server,
>> including Fedora DS, can support Solaris naming service. However,
>> getting the server "properly configured" can be tricky.
>>
>> However, since Sun's own directory server ("Sun Java Enterprise
>> System Directory Server") is so very similar to Fedora DS, much of
>> the same preparation methods and documentation regarding SunDS will
>> apply directly to Fedora DS.
>>
>> A good starting point would be Gary Tay's fine documentation at:
>> http://web.singnet.com.sg/~garyttt/
>>
>> Gary's docs were written around iPlanet/Sun DS, but as I mentioned,
>> pretty much all of this should also apply to Fedora DS.
>>
>> Good luck!
>> -- George
>>
>>
>> Brian Martinez wrote:
>>
>>> All,
>>>
>>> Does the Fedora DS support Solaris Clients? If so, where can I find
>>> information, schema examples, etc....
>>>
>>> Thanks in advance,
>>> Brian
>>>
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>
>>
>>
>> --
>> Fedora-directory-users mailing list Fedora-directory-users(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
> --
> Fedora-directory-users mailing list Fedora-directory-users(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users
FDS folks,
I just tried my procedures on a Solaris8 Native LDAP Client, It works!!!
I forgot to mention ONE IMPORTANT point, APPLY the latest kernel and
LDAP patches prior to anything, otherwise some error in /etc/pam.conf
may render your LDAP client "un-loginable" due to unrecognizable
keywords/options/flags.
Solaris8: kernel patch + 108993
Solaris9: kernel patch + 112960
Solaris10: I don't know, I have not touched one such yet, check sunsolve
patches info.
Some modifications to 99user.ldif is done by me, I am not sure if they
are really needed, anyway I list them here as FYI:
I removed these lines from 99user.ldif
- modifiersName: cn=directory manager
- mModifyTimestamp: 20050427082543Z
- All "aci:" lines
- nsSchemaCSN: 429ddf1d000000000000
Note that after setting up 99user.ldif in
$LDAP_ROOT/slapd-`hostname`/config/schema directory, you have to restart
slapd to load the new schema definitions, as Rich have said earlier.
You may use this sample ldif to create proxyAgent and sample ldapclient
profiles.ldif, it assumes password of proxyAgent is "password", if you
want to use a different password for proxyAgent, you may use
/opt/fedora-ds/slapd-`hostname`/getpwenc to find the {CRYPT} hash, for
the {NS1} hash, there is a trick to get a generated on a Solaris8
machine, read my post at
http://forum.sun.com/thread.jspa?threadID=25436&tstart=0
# cat proxyAgent_and_sample_profiles.ldif
dn: ou=profile,dc=example,dc=com
ou: profile
objectClass: top
objectClass: organizationalUnit
dn: cn=proxyagent,ou=profile,dc=example,dc=com
cn: proxyagent
sn: proxyagent
objectClass: top
objectClass: person
userPassword: {CRYPT}l14aeXtphVSUg
dn: cn=default,ou=profile,dc=example,dc=com
objectClass: top
objectClass: DUAConfigProfile
defaultServerList: ldap1.example.com
defaultSearchBase: dc=example,dc=com
authenticationMethod: simple
followReferrals: TRUE
defaultSearchScope: one
searchTimeLimit: 30
profileTTL: 43200
cn: default
credentialLevel: proxy
bindTimeLimit: 2
dn: cn=tls_profile,ou=profile,dc=example,dc=com
objectClass: top
objectClass: DUAConfigProfile
defaultServerList: ldap1.example.com
defaultSearchBase: dc=example,dc=com
authenticationMethod: tls:simple
followReferrals: FALSE
defaultSearchScope: one
searchTimeLimit: 30
profileTTL: 43200
bindTimeLimit: 10
cn: tls_profile
credentialLevel: proxy
serviceSearchDescriptor: passwd: ou=People,dc=example,dc=com
serviceSearchDescriptor: group: ou=group,dc=example,dc=com
serviceSearchDescriptor: shadow: ou=People,dc=example,dc=com
FDS seems to check tightly on objectClasses, if I omit "objectClass:
top" from the profile definitions, it will complain that "objectClass:
DUAConfigProfile" is not a valid "attribute" during ldapadd.
This is the /var/ldap/ldap_client_file I used:
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= ldap1.example.com
NS_LDAP_SEARCH_BASEDN= dc=example,dc=com
NS_LDAP_AUTH= simple
NS_LDAP_SEARCH_REF= TRUE
NS_LDAP_SEARCH_SCOPE= one
NS_LDAP_SEARCH_TIME= 30
NS_LDAP_CACHETTL= 43200
NS_LDAP_PROFILE= default
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_BIND_TIME= 2
And /var/ldap/ldap_client_cred, it assumes proxyAgent password is
"password"
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=platts,dc=mhm,dc=mhc
NS_LDAP_BINDPASSWD= {NS1}ecfa88f3a945c411
Make sure you "chmod 400 /var/ldap/ldap_client_???"
Copy /etc/nsswitch.ldap to /etc/nsswitch.conf, edit nsswitch.conf and
make sure that these lines exist:
passwd: files ldap
group: files ldap
shadow: files ldap
hosts: files dns
Set Solaris LDAP domain name, this is a one time execution only
# echo "example.com" >/etc/defaultdomain
# domainname `cat /etc/defaultdomain`
Now try to refresh ldap_cachemgr and nscd
# /etc/init.d/ldap.client stop
# /etc/init.d/ldap.client start
# ps -ef | grep ldap
# /usr/lib/ldap/ldap_cachemgr -g
# /etc/init.d/nscd stop
# /etc/init.d/nscd start
# ps -ef | grep nscd
Note that I DID NOT EVEN BOTHER to run "ldapclient init ..." or
"ldapclient manual ...", if I DO run it, I have to press CTRL-C to break
it so it runs to completion.
IMPORTANT NOTE: One side effect of running "ldapclient" is that it
resets "hosts: files dns" in /etc/nsswitch.conf to "hosts: ldap files"
and this affects the DNS names lookup, it is always advisable to double
check the "hosts:" entry in /etc/nsswitch.conf and adjust it back to the
desired "files dns" setting.
I used the sample pam.conf from this URL with all "pam_unix_cred.so.1"
lines commenting out as they are meant for Solaris10, do not comment
them out if you are using Solaris10.
http://docs.sun.com/app/docs/doc/816-4556/6maort2te?a=view
Have funs and good lucks!
Rgds
Gary
-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Tay,
Gary
Sent: Friday, July 15, 2005 12:39 PM
To: General discussion list for the Fedora Directory server project.
Subject: **Caution-External**: RE: [Fedora-directory-users] Solaris
Native LDAP Client againstFDS7.1 Server
IIRC the two .schema files in my OpenLDAP HOW-TO is actually equivalent
to the 99user.ldif (residing in
$LDAP_ROOT/slapd-`hostname`/config/schema) file provided by SUN ONE
DS5.2, i.e.
DUAConfigProfile.schema + solaris.schema = 99user.ldif.
So if there is an existing Solaris8/9 DS5.2 server, simply copy
99user.ldif from DS5.2 over to FDS7.1.
Someone who is using Oracle Internet Directory had asked me in
supportforum.sun.com how to configure Solaris Native LDAP Client to
authenticate against OID, I had some brief instructions given there, I
reproduced and modified a bit as a quick notes here.
PLEASE NOTE that I haven't tried these steps but believe it should work
as FDS7.1 is similar to DS5.2, anyone has tried these please feel free
to comment and add.
===
To make a Solaris Native LDAP Clients (Solaris8 or Solaris9) worked
against FDS7.1 Server, you would have to do a little hackings to make
FDS7.1 Server acts like a SUN DS5.2 ldapclient profile(s) provider,
described as in the following notes,
- Add "nisDomain" to rootDN object (eg: object is dc=example,dc=com) so
that "ldapclient" will be able to find this nisDomainObject, using
ldapmodify or GUI based tools.
objectClass: nisDomainObject
nisDomain: example.com
- Copy schema 99user.ldif from DS5.2 to FDS7.1
- Create ou=profile OU object and add cn=ProxyAgent as a proxy
credentials proxy user under it
- Create "default" or "customized" ldapclient profile(s) under the
ou=profile subtree for simple bind or simple bind + TLS or whatever,
using manually prepared ldif file or ldif generated by "ldapclient
genprofile" command, read "man ldapclient" for more details.
- Setup two ACLs under dc=example,dc=com object, ACL1 should appear
before ACL2, they are actually present in any typical SUN ONE DS5.2
1. LDAP_Naming_Services_deny_write_access
(targetattr =
"cn||uid||uidNumber||gidNumber||homeDirectory||shadowLastChange||shadowM
in||shadowMax||shadowWarning||shadowInactive||shadowExpire||shadowFlag||
memberUid")(version 3.0; acl LDAP_Naming_Services_deny_write_access;
deny (write) userdn = "ldap:///self";)
2.LDAP_Naming_Services_proxy_password_read
(target="ldap:///dc=example,dc=com")(targetattr="userPassword")(version
3.0; acl LDAP_Naming_Services_proxy_password_read; allow
(compare,read,search) userdn =
"ldap:///cn=proxyagent,ou=profile,dc=example,dc=com";)
Tips: delete the word "read" if you do not want "ldaplist -l passwd" to
list userPassword(s), i.e. it becomes:
(target="ldap:///dc=example,dc=com")(targetattr="userPassword")(version
3.0; acl LDAP_Naming_Services_proxy_password_read; allow
(compare,search) userdn =
"ldap:///cn=proxyagent,ou=profile,dc=example,dc=com";)
- It is advisable to set password hash scheme to CRYPT in FDS7.1.
- It is advisable to add "shadowAccount" objectclass to your user
entries, on top of "posixAccount".
- Note that Solaris "ldapclient" has an irritating act that it will
reset the "hosts:" entry to "hosts: files ldap" or something that puts
"ldap" in front of "dns", this should be adjusted back to "hosts: files
dns", otherwise something like telnet/ftp/ssh will break on hostname
lookup as the hosts lookup using "ldap" goes recursive.
Rgds
Gary
-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Rich
Megginson
Sent: Friday, July 15, 2005 3:21 AM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] Solaris Client
Brian Martinez wrote:
> George,
>
> That is correct, we are attempting to use the FDS7 as a central
> authentication system for Solaris 10 NSS Clients with a PAM backend.
>
> We believe that we are missing the proper schemas on the server
> (DUAConfigProfile and Solaris) to support the Solaris Clients. The
> ones on Tay's website seem to be in the wrong format (schema instead
> of ldif)...or we just dont know how to import them!
You can use this script
http://www.directory.fedora.redhat.com/download/ol-schema-migrate.pl
found on this page
http://directory.fedora.redhat.com/wiki/Howto:OpenLDAPMigration
to convert .schema files to .ldif schema files. e.g.
perl ol-schema-migrate.pl solaris.schema >
slapd-myhost/config/schema/61solaris.ldif
Then restart slapd
>
> We have been scrounging his site for clues/ideas...developers on the
> client side are convinced the server is the issue...developers on the
> server side believe it is the client. My take is that we already have
> the server "most" of the way, because we are successfully
> authenticating Linux clients securely to the FDS7 server and we are
> missing some essential piece on the server side to solve the Solaris
> puzzle.
>
> If you have any further thoughts, ideas, or prayers...feel free to
> send them our way.
>
>> From: "George Holbert" <gholbert(a)broadcom.com>
>> Reply-To: "General discussion list for the Fedora Directory server
>> project." <fedora-directory-users(a)redhat.com>
>> To: "General discussion list for the Fedora Directory server
>> project." <fedora-directory-users(a)redhat.com>
>> Subject: Re: [Fedora-directory-users] Solaris Client
>> Date: Thu, 14 Jul 2005 11:08:06 -0700
>>
>> Hi Brian,
>>
>> By "Solaris Clients", I assume you mean Solaris naming service (for
>> passwd, group, etc.).
>>
>> The answer is yes. Any modern, properly configured LDAP server,
>> including Fedora DS, can support Solaris naming service. However,
>> getting the server "properly configured" can be tricky.
>>
>> However, since Sun's own directory server ("Sun Java Enterprise
>> System Directory Server") is so very similar to Fedora DS, much of
>> the same preparation methods and documentation regarding SunDS will
>> apply directly to Fedora DS.
>>
>> A good starting point would be Gary Tay's fine documentation at:
>> http://web.singnet.com.sg/~garyttt/
>>
>> Gary's docs were written around iPlanet/Sun DS, but as I mentioned,
>> pretty much all of this should also apply to Fedora DS.
>>
>> Good luck!
>> -- George
>>
>>
>> Brian Martinez wrote:
>>
>>> All,
>>>
>>> Does the Fedora DS support Solaris Clients? If so, where can I find
>>> information, schema examples, etc....
>>>
>>> Thanks in advance,
>>> Brian
>>>
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>
>>
>>
>> --
>> Fedora-directory-users mailing list Fedora-directory-users(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
> --
> Fedora-directory-users mailing list Fedora-directory-users(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users