[Freeipa-users] consulting?
Rich Megginson
rmeggins at redhat.com
Tue Jan 24 22:00:47 UTC 2012
On 01/24/2012 02:51 PM, Jimmy wrote:
> The cert I'm using both in the sync agreement and in the openssl
> command has the serial
> number: 68:10:1c:98:3b:5c:e7:8d:43:ec:e3:e7:6a:e7:de:27
> (AD-server-cert.cer.) The serial number that shows in the pcap coming
> from AD in both instances is 61:13:fd:30:00:00:00:00:00:04 (line 196
> in the fpaste)
61:13:fd:30:00:00:00:00:00:04 looks like the AD server cert, not the AD
CA cert:
193. Certificate (id-at-commonName=xxx-ad.xxxad.xxx.xxx)
the one at line 217 looks like the AD CA cert, but unfortunately the
serial number nor any other identifying information is in the pcap output
217. Distinguished Name:
(id-at-commonName=xxxad-XXX-AD-CA,dc=xxxad,dc=xxx,dc=xxx)
which corresponds to this from the s_client output:
51. Acceptable client certificate CA names
52. /DC=xxx/DC=xxx/DC=xxxad/CN=xxxad-xxx-AD-CA
You can use openssl s_client -connect xxx-ad.xxx.xxx:636 -showcerts
-CAfile /home/winsync/AD-server-cert.cer
which will show the contents of all of the certs, not just the AD server
cert
>
> OpenSSL command: openssl s_client -connect xxx-ad.xxx.xxx:636 -CAfile
> /home/winsync/AD-server-cert.cer
> OpenSSL output- http://fpaste.org/Zx5N/
>
> Both the output of openssl and the pcap of the openssl session look
> successful here.
What about the ldapsearch commands?
>
> Thanks for your help.
> Jimmy
>
> On Tue, Jan 24, 2012 at 4:20 PM, Rich Megginson <rmeggins at redhat.com
> <mailto:rmeggins at redhat.com>> wrote:
>
> On 01/24/2012 02:07 PM, Jimmy wrote:
>> certutil output:
>> http://fpaste.org/tJDW/
>>
>> pcap output (exported from Wireshark, looks messy):
>> http://fpaste.org/M3Gr/
> hard to tell from the pcap output, but is
>
> Serial Number: 68:10:1c:98:3b:5c:e7:8d:43:ec:e3:e7:6a:e7:de:27
> Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
> Issuer: "CN=xxxad-xxx-AD-CA,DC=xxxad,DC=xxx,DC=xxx"
> Validity:
> Not Before: Thu Jan 19 17:52:07 2012
> Not After : Thu Jan 19 18:02:04 2017
> Subject: "CN=xxxad-xxx-AD-CA,DC=xxxad,DC=xxx,DC=xxx"
>
> the same cert as the cert from the pcap output that is called
> Distinguished Name:
> (id-at-commonName=xxxad-XXX-AD-CA,dc=xxxad,dc=xxx,dc=xxx)
>
> because this appears to be the AD CA cert sent over from AD as
> part of the SSL handshake
>
> There are a couple of good tools to use to diagnose/debug
> connection problems between 389 and AD before you attempt to use
> winsync with ssl.
>
> The first is openssl s_client
> openssl s_client -connect ADhost:636 -CAfile /path/to/adca.cer
>
> The second is mozldap ldapsearch:
> /usr/lib64/mozldap/ldapsearch -h ADHost -p 636 -Z -P
> /etc/dirsrv/slapd-INST/cert8.db -s base -b "" "objectclass=*"
>
> The third is openldap ldapsearch:
> LDAPTLS_CACERT=/path/to/adca.cer ldapsearch -x -h ADHost -p 636 -s
> base -b "" "objectclass=*"
>
> For the last you can add "-d 1" to get detailed SSL error messages
>>
>> On Tue, Jan 24, 2012 at 3:29 PM, Rich Megginson
>> <rmeggins at redhat.com <mailto:rmeggins at redhat.com>> wrote:
>>
>> On 01/24/2012 01:26 PM, Jimmy wrote:
>>> The sync is still not working so I was going back through
>>> the docs to see what I missed. I know this is from an older
>>> version of IPA but I was looking here:
>>> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html#sect-Installation_and_Deployment_Guide-Prerequisites-Setting_up_Active_Directory
>>>
>>>
>>> and used this method to get the AD certificate server cert.
>> You mean "CA cert" not "server cert", right?
>>>
>>> 1.
>>> Navigate to My Network Places and drill down to the CA
>>> distribution point. On Windows 2003 Server this is
>>> typically |C:\WINDOWS\system32\certsrv\CertEnroll\|
>>> 2.
>>> Double-click the security certificate file
>>> (|.crt| file) to display the *Certificate* dialog box.
>>> 3.
>>> On the *Details* tab, click *Copy to File* to start
>>> the *Certificate Export Wizard*.
>>> 4.
>>> Click *Next*, select *Base-64 encoded X.509
>>> (.CER)* and then click *Next*.
>>> 5.
>>> Specify a suitable directory and file name for the
>>> exported file. The file name is not important. Click
>>> *Next* to export the certificate, and then click
>>> *Finish*. You should receive a message stating that
>>> the export was successful.
>>> 6.
>>> Click *OK* to exit the wizard.
>>>
>>> But when I run the command to create the sync
>>> agreement(pointing to the cert I got in the step above) the
>>> ssl connection fails and if I look at tcpdump of the
>>> connection I see that the AD server is not sending the cert
>>> that I have imported with the sync agreement. I have used
>>> certutil to verify that I have the same cert(same serial
>>> number and same public key) in the 389 server as the one in
>>> the AD server (
>>> C:\WINDOWS\system32\certsrv\CertEnroll\). The AD server is
>>> sending a completely different cert, and I have been unable
>>> to find the cert in the certificate stores on the AD server
>>> so I'm not sure where the bogus cert is coming from. Before
>>> I added the certificate services role the certsrv\certenroll
>>> directory was not present so I know this was created when I
>>> added that role to the AD server.
>>>
>>> The pcap can be seen here:
>>> http://www.pcapr.net/view/g17jimmy/2012/0/2/11/ldaps3.pcap.html (sorry,
>>> registration required on that site, I didn't have anywhere
>>> else to put it.)
>> Can you try fpaste.org <http://fpaste.org>?
>>>
>>> Any idea why AD would be sending me the wrong cert and where
>>> it's coming from? Yes, I know this isn't MS just trying to
>>> get these 2 systems to talk ;).
>>>
>>> On Tue, Jan 24, 2012 at 1:18 PM, Rich Megginson
>>> <rmeggins at redhat.com <mailto:rmeggins at redhat.com>> wrote:
>>>
>>> On 01/24/2012 11:03 AM, Jimmy wrote:
>>>> Ok, I just realized that I only have passsync and not
>>>> winsync, stupid oversight, but now that I know it I
>>>> need to get winsync. Is there a location to download
>>>> binaries or must I compile from source? I see the
>>>> binaries for passsync on the directory server project
>>>> downloads but I don't see the same for winsync.
>>> winsync is built-in to 389 - there isn't any additional
>>> component that you need to install.
>>>
>>>>
>>>> Thanks,
>>>> Jim
>>>>
>>>> On Mon, Jan 23, 2012 at 1:33 PM, Rich Megginson
>>>> <rmeggins at redhat.com <mailto:rmeggins at redhat.com>> wrote:
>>>>
>>>> On 01/23/2012 11:34 AM, Jimmy wrote:
>>>>> I did create the winsync user and it is an admin.
>>>>>
>>>>> I will fix the ip address(change to hostname,) I
>>>>> only did it that was because this is currently a
>>>>> test system so I can figure out how to get it all
>>>>> working.
>>>> ok - once you do that, you can check the 389 errors
>>>> log at /var/log/dirsrv/slapd-INST/errors to see if
>>>> winsync is logging any errors
>>>>
>>>>>
>>>>> On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson
>>>>> <rmeggins at redhat.com <mailto:rmeggins at redhat.com>>
>>>>> wrote:
>>>>>
>>>>> On 01/23/2012 10:52 AM, Jimmy wrote:
>>>>>> That's what I was thinking, and what I did,
>>>>>> but it still doesn't replicate new users.
>>>>>> This is the command I used:
>>>>>>
>>>>>> ipa-replica-manage connect --passsync
>>>>>> --binddn
>>>>>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp
>>>>>> --bindpw=******** --cacert
>>>>>> /home/winsync/AD-server-cert.cer
>>>>>> 192.168.201.150 -v
>>>>>
>>>>> Did you create the user
>>>>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp?
>>>>> And does this user have the rights to perform
>>>>> sync? (e.g. has to have replicator rights, or
>>>>> be some sort of admin) - see
>>>>> http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx
>>>>> - the AD user must have replication rights and
>>>>> write rights.
>>>>>
>>>>> In addition, since this process uses SSL, you
>>>>> cannot use an IP address, you must use a
>>>>> hostname, or the SSL cert hostname checking
>>>>> (for MITM) will fail.
>>>>>
>>>>>>
>>>>>> On Mon, Jan 23, 2012 at 12:30 PM, Rich
>>>>>> Megginson <rmeggins at redhat.com
>>>>>> <mailto:rmeggins at redhat.com>> wrote:
>>>>>>
>>>>>> On 01/23/2012 10:19 AM, Jimmy wrote:
>>>>>>> Here's what I found in the DS admin
>>>>>>> guide. Is this all that's needed to
>>>>>>> create the sync agreement?
>>>>>> Not with ipa - you should use the
>>>>>> ipa-replica-manage command instead
>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> add sync agreement:
>>>>>>> ldapmodify -x -D "cn=Directory Manager" -W
>>>>>>> Enter LDAP Password: *******
>>>>>>> dn: cn=ExampleSyncAgreement,cn=sync
>>>>>>> replica,cn=dc=example\,dc=com,cn=mapping
>>>>>>> tree,cn=config
>>>>>> it should be cn=replica, not cn=sync
>>>>>> replica - does it use the latter in the
>>>>>> Admin Guide?
>>>>>>
>>>>>>> changetype: add
>>>>>>> objectclass: top
>>>>>>> objectclass: nsDSWindowsReplicationAgreement
>>>>>>> cn: ExampleSyncAgreement
>>>>>>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1
>>>>>>> nsds7DirectoryReplicaSubtree:
>>>>>>> ou=People,dc=example,dc=com
>>>>>>> nsds7NewWinUserSyncEnabled: on
>>>>>>> nsds7NewWinGroupSyncEnabled: on
>>>>>>> nsds7WindowsDomain: ad1
>>>>>>> nsDS5ReplicaRoot: dc=example,dc=com
>>>>>>> nsDS5ReplicaHost: ad1.windows-server.com
>>>>>>> <http://ad1.windows-server.com>
>>>>>>> nsDS5ReplicaPort: 389
>>>>>>> nsDS5ReplicaBindDN: cn=sync user,cn=config
>>>>>>> nsDS5ReplicaBindCredentials:
>>>>>>> {DES}ffGad646dT0nnsT8nJOaMA==
>>>>>>> nsDS5ReplicaTransportInfo: TLS
>>>>>>> winSyncInterval: 1200
>>>>>>>
>>>>>>> On Fri, Jan 20, 2012 at 3:28 PM, Rich
>>>>>>> Megginson <rmeggins at redhat.com
>>>>>>> <mailto:rmeggins at redhat.com>> wrote:
>>>>>>>
>>>>>>> On 01/20/2012 01:08 PM, Jimmy wrote:
>>>>>>>> That was it! I have passwords
>>>>>>>> syncing, *BUT*(at the risk of
>>>>>>>> sounding stupid)-- is it not
>>>>>>>> possible to also sync(add) the
>>>>>>>> users from AD to DS?
>>>>>>> Yes, it is. Just configure IPA
>>>>>>> Windows Sync
>>>>>>>
>>>>>>>> I created a new user in AD and it
>>>>>>>> doesn't propogate to DS, just says:
>>>>>>>>
>>>>>>>> attempting to sync password for
>>>>>>>> testuser3
>>>>>>>> searching for
>>>>>>>> (ntuserdomainid=testuser3)
>>>>>>>> There are no entries that match:
>>>>>>>> testuser3
>>>>>>>> deferring password change for testuser3
>>>>>>>>
>>>>>>>> On Fri, Jan 20, 2012 at 2:46 PM,
>>>>>>>> Rich Megginson <rmeggins at redhat.com
>>>>>>>> <mailto:rmeggins at redhat.com>> wrote:
>>>>>>>>
>>>>>>>> On 01/20/2012 12:46 PM, Jimmy
>>>>>>>> wrote:
>>>>>>>>> Getting close here... Now I
>>>>>>>>> see this message in the sync
>>>>>>>>> log file:
>>>>>>>>>
>>>>>>>>> attempting to sync password
>>>>>>>>> for testuser
>>>>>>>>> searching for
>>>>>>>>> (ntuserdomainid=testuser)
>>>>>>>>> ldap error in queryusername
>>>>>>>>> 32: no such object
>>>>>>>>> deferring password change for
>>>>>>>>> testuser
>>>>>>>> This usually means the search
>>>>>>>> base is incorrect or not
>>>>>>>> found. You can look at the 389
>>>>>>>> access log to see what it was
>>>>>>>> using as the search criteria.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jan 20, 2012 at 12:23
>>>>>>>>> PM, Rich Megginson
>>>>>>>>> <rmeggins at redhat.com
>>>>>>>>> <mailto:rmeggins at redhat.com>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On 01/20/2012 10:23 AM,
>>>>>>>>> Jimmy wrote:
>>>>>>>>>> You are correct. I had
>>>>>>>>>> installed as an
>>>>>>>>>> Enterprise root, but the
>>>>>>>>>> doc I was
>>>>>>>>>> reading(original link)
>>>>>>>>>> seemed to say that I had
>>>>>>>>>> to do the certreq
>>>>>>>>>> manually, my bad. I think
>>>>>>>>>> I'm getting closer I can
>>>>>>>>>> establish an openssl
>>>>>>>>>> connection from DS to AD
>>>>>>>>>> but I get these errors:
>>>>>>>>>>
>>>>>>>>>> openssl s_client
>>>>>>>>>> -connect
>>>>>>>>>> 192.168.201.150:636
>>>>>>>>>> <http://192.168.201.150:636>
>>>>>>>>>> -showcerts -CAfile dsca.crt
>>>>>>>>>> CONNECTED(00000003)
>>>>>>>>>> depth=0 CN =
>>>>>>>>>> csp-ad.cspad.pdh.csp
>>>>>>>>>> verify
>>>>>>>>>> error:num=20:unable to
>>>>>>>>>> get local issuer certificate
>>>>>>>>>> verify return:1
>>>>>>>>>> depth=0 CN =
>>>>>>>>>> csp-ad.cspad.pdh.csp
>>>>>>>>>> verify
>>>>>>>>>> error:num=27:certificate
>>>>>>>>>> not trusted
>>>>>>>>>> verify return:1
>>>>>>>>>> depth=0 CN =
>>>>>>>>>> csp-ad.cspad.pdh.csp
>>>>>>>>>> verify
>>>>>>>>>> error:num=21:unable to
>>>>>>>>>> verify the first certificate
>>>>>>>>>> verify return:1
>>>>>>>>>>
>>>>>>>>>> I thought I had imported
>>>>>>>>>> the cert from AD but it
>>>>>>>>>> doesn't seem so. I'm
>>>>>>>>>> still researching but if
>>>>>>>>>> you guys have a
>>>>>>>>>> suggestion let me know.
>>>>>>>>> Is dsca.crt the CA that
>>>>>>>>> issued the DS server
>>>>>>>>> cert? If so, that won't
>>>>>>>>> work. You need the CA
>>>>>>>>> cert from the CA that
>>>>>>>>> issued the AD server cert
>>>>>>>>> (i.e. the CA cert from the
>>>>>>>>> MS Enterprise Root CA).
>>>>>>>>>
>>>>>>>>>> -J
>>>>>>>>>>
>>>>>>>>>> On Thu, Jan 19, 2012 at
>>>>>>>>>> 5:04 PM, Rich Megginson
>>>>>>>>>> <rmeggins at redhat.com
>>>>>>>>>> <mailto:rmeggins at redhat.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 01/19/2012 02:59
>>>>>>>>>> PM, Jimmy wrote:
>>>>>>>>>>> ok. I started from
>>>>>>>>>>> scratch this week on
>>>>>>>>>>> this and I think
>>>>>>>>>>> I've got the right
>>>>>>>>>>> doc and understand
>>>>>>>>>>> better where this is
>>>>>>>>>>> going. My problem
>>>>>>>>>>> now is that when
>>>>>>>>>>> configuring SSL on
>>>>>>>>>>> the AD server (step
>>>>>>>>>>> c in this url:
>>>>>>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service )
>>>>>>>>>>>
>>>>>>>>>>> I get this error:
>>>>>>>>>>>
>>>>>>>>>>> certreq -submit
>>>>>>>>>>> request.req certnew.cer
>>>>>>>>>>> Active Directory
>>>>>>>>>>> Enrollment Policy
>>>>>>>>>>>
>>>>>>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42}
>>>>>>>>>>> ldap:
>>>>>>>>>>> RequestId: 3
>>>>>>>>>>> RequestId: "3"
>>>>>>>>>>> Certificate not
>>>>>>>>>>> issued (Denied)
>>>>>>>>>>> Denied by Policy
>>>>>>>>>>> Module 0x80094801,
>>>>>>>>>>> The request does not
>>>>>>>>>>> contain a
>>>>>>>>>>> certificate template
>>>>>>>>>>> extension or the
>>>>>>>>>>> CertificateTemplate
>>>>>>>>>>> request attribute.
>>>>>>>>>>> The request
>>>>>>>>>>> contains no
>>>>>>>>>>> certificate template
>>>>>>>>>>> information.
>>>>>>>>>>> 0x80094801
>>>>>>>>>>> (-2146875391
>>>>>>>>>>> <tel:%28-2146875391>)
>>>>>>>>>>> Certificate Request
>>>>>>>>>>> Processor: The
>>>>>>>>>>> request contains no
>>>>>>>>>>> certificate template
>>>>>>>>>>> information.
>>>>>>>>>>> 0x80094801
>>>>>>>>>>> (-2146875391
>>>>>>>>>>> <tel:%28-2146875391>)
>>>>>>>>>>> Denied by Policy
>>>>>>>>>>> Module 0x80094801,
>>>>>>>>>>> The request does not
>>>>>>>>>>> contain a
>>>>>>>>>>> certificate template
>>>>>>>>>>> extension or the
>>>>>>>>>>> CertificateTemplate
>>>>>>>>>>> request attribute.
>>>>>>>>>>>
>>>>>>>>>>> The RH doc says to
>>>>>>>>>>> use the browser if
>>>>>>>>>>> an error occurs and
>>>>>>>>>>> IIS is running but
>>>>>>>>>>> I'm not running IIS.
>>>>>>>>>>> I researched that
>>>>>>>>>>> error but didn't
>>>>>>>>>>> find anything that
>>>>>>>>>>> helps with FreeIPA
>>>>>>>>>>> and passsync.
>>>>>>>>>> Hmm - try installing
>>>>>>>>>> Microsoft Certificate
>>>>>>>>>> Authority in
>>>>>>>>>> Enterprise Root CA
>>>>>>>>>> mode - it will
>>>>>>>>>> usually automatically
>>>>>>>>>> create and install
>>>>>>>>>> the AD server cert.
>>>>>>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jimmy
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jan 11, 2012
>>>>>>>>>>> at 3:32 PM, Rich
>>>>>>>>>>> Megginson
>>>>>>>>>>> <rmeggins at redhat.com
>>>>>>>>>>> <mailto:rmeggins at redhat.com>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 01/11/2012
>>>>>>>>>>> 11:22 AM, Jimmy
>>>>>>>>>>> wrote:
>>>>>>>>>>>> We need to be
>>>>>>>>>>>> able to
>>>>>>>>>>>> replicate
>>>>>>>>>>>> user/pass
>>>>>>>>>>>> between Windows
>>>>>>>>>>>> 2008 AD and
>>>>>>>>>>>> FreeIPA.
>>>>>>>>>>>
>>>>>>>>>>> That's what IPA
>>>>>>>>>>> Windows Sync is
>>>>>>>>>>> supposed to do.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> I have followed
>>>>>>>>>>>> many different
>>>>>>>>>>>> documents and
>>>>>>>>>>>> posted here
>>>>>>>>>>>> about it and
>>>>>>>>>>>> from what I've
>>>>>>>>>>>> read and
>>>>>>>>>>>> procedures I've
>>>>>>>>>>>> followed we are
>>>>>>>>>>>> unable to
>>>>>>>>>>>> accomplish this.
>>>>>>>>>>>
>>>>>>>>>>> What have you
>>>>>>>>>>> tried, and what
>>>>>>>>>>> problems have
>>>>>>>>>>> you run into?
>>>>>>>>>>>
>>>>>>>>>>>> It doesn't need
>>>>>>>>>>>> to be a full
>>>>>>>>>>>> trust.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jan 10,
>>>>>>>>>>>> 2012 at 3:03
>>>>>>>>>>>> AM, Jan Zelený
>>>>>>>>>>>> <jzeleny at redhat.com
>>>>>>>>>>>> <mailto:jzeleny at redhat.com>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> > Just
>>>>>>>>>>>> wondering
>>>>>>>>>>>> if there
>>>>>>>>>>>> was anyone
>>>>>>>>>>>> listening
>>>>>>>>>>>> on the list
>>>>>>>>>>>> that might be
>>>>>>>>>>>> > available
>>>>>>>>>>>> for little
>>>>>>>>>>>> work
>>>>>>>>>>>> integrating
>>>>>>>>>>>> FreeIPA
>>>>>>>>>>>> with Active
>>>>>>>>>>>> Directory
>>>>>>>>>>>> >
>>>>>>>>>>>> (preferrably in
>>>>>>>>>>>> the south
>>>>>>>>>>>> east US.) I
>>>>>>>>>>>> hope this
>>>>>>>>>>>> isn't
>>>>>>>>>>>> against the
>>>>>>>>>>>> list
>>>>>>>>>>>> > rules, I
>>>>>>>>>>>> just
>>>>>>>>>>>> thought one
>>>>>>>>>>>> of you guys
>>>>>>>>>>>> could help
>>>>>>>>>>>> or point me
>>>>>>>>>>>> in the right
>>>>>>>>>>>> > direction.
>>>>>>>>>>>>
>>>>>>>>>>>> If you want
>>>>>>>>>>>> some help,
>>>>>>>>>>>> it is
>>>>>>>>>>>> certainly
>>>>>>>>>>>> not against
>>>>>>>>>>>> list rules
>>>>>>>>>>>> ;-) But in that
>>>>>>>>>>>> case, it
>>>>>>>>>>>> would be
>>>>>>>>>>>> much better
>>>>>>>>>>>> if you
>>>>>>>>>>>> asked what
>>>>>>>>>>>> exactly do
>>>>>>>>>>>> you need.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not an
>>>>>>>>>>>> AD expert,
>>>>>>>>>>>> but a
>>>>>>>>>>>> couple
>>>>>>>>>>>> tips: If
>>>>>>>>>>>> you are
>>>>>>>>>>>> looking for
>>>>>>>>>>>> cross-domain
>>>>>>>>>>>> (cross-realm)
>>>>>>>>>>>> trust, then
>>>>>>>>>>>> you might
>>>>>>>>>>>> be a bit
>>>>>>>>>>>> disappointed,
>>>>>>>>>>>> it is still in
>>>>>>>>>>>> development, so
>>>>>>>>>>>> it probably
>>>>>>>>>>>> won't be
>>>>>>>>>>>> 100%
>>>>>>>>>>>> functional
>>>>>>>>>>>> at this moment.
>>>>>>>>>>>>
>>>>>>>>>>>> If you are
>>>>>>>>>>>> looking for
>>>>>>>>>>>> something
>>>>>>>>>>>> else, could
>>>>>>>>>>>> you be a
>>>>>>>>>>>> little more
>>>>>>>>>>>> specific what
>>>>>>>>>>>> it is?
>>>>>>>>>>>>
>>>>>>>>>>>> I also
>>>>>>>>>>>> recommend
>>>>>>>>>>>> starting
>>>>>>>>>>>> with
>>>>>>>>>>>> reading
>>>>>>>>>>>> some doc:
>>>>>>>>>>>> http://freeipa.org/page/DocumentationPortal
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Jan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Freeipa-users mailing list
>>>>>>>>>>>> Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120124/500eb178/attachment.htm>
More information about the Freeipa-users
mailing list