[Freeipa-users] Creating password sync
Rich Megginson
rmeggins at redhat.com
Tue Feb 4 21:42:12 UTC 2014
On 02/04/2014 02:39 PM, Todd Maugh wrote:
>
> How did you specify the CA cert of the CA that issued the IdM ldap
> server cert?
>
> On the AD server (qatestdc2) i downloaded the CA from the IDM server
> (se-idm-01) from the web url
>
> http://se-idm-01.boingo.com/|ipa/config/ca.crt|
>
> then I ran this
> cd "C:\Program Files\Red Hat Directory Password Synchronization"
>
> certutil.exe -d . -A -n "SE-IDM-01.BOINGO.com CA" -t CT,, -a -i IDMCA.crt
>
> How did you specify that you want to check to see if the server FQDN
> is the same as the cn in the IdM ldap server cert subject DN?
>
> I do not believe that I did this, as I am not sure how
For both of my questions, I meant - how did you do those in your LDAP
client that you ran on AD?
>
>> Host supports SSL, SSL cipher strength = 256 bits
>> Established connection to se-idm-01.boingo.com:636
>> <http://se-idm-01.boingo.com:636>.
>> Retrieving base DSA information...
>> Getting 1 entries:
>> Dn: (RootDSE)
>> dataversion: 020140131234000;
>> defaultnamingcontext: dc=boingo,dc=com;
>> lastusn: 5177;
>> namingContexts: dc=boingo,dc=com;
>> netscapemdsuffix: cn=ldap://dc=se-idm-01,dc=boingo,dc=com:389;
>> objectClass: top;
>> supportedControl (21): 2.16.840.1.113730.3.4.2;
>> 2.16.840.1.113730.3.4.3; 2.16.840.1.113730.3.4.4;
>> 2.16.840.1.113730.3.4.5; 1.2.840.113556.1.4.473 = ( SORT );
>> 2.16.840.1.113730.3.4.9 = ( VLVREQUEST ); 2.16.840.1.113730.3.4.16;
>> 2.16.840.1.113730.3.4.15; 2.16.840.1.113730.3.4.17;
>> 2.16.840.1.113730.3.4.19; 1.3.6.1.4.1.42.2.27.8.5.1;
>> 1.3.6.1.4.1.42.2.27.9.5.2; 1.2.840.113556.1.4.319 = ( PAGED_RESULT );
>> 1.3.6.1.4.1.42.2.27.9.5.8; 1.3.6.1.4.1.4203.666.5.16;
>> 2.16.840.1.113730.3.4.14; 2.16.840.1.113730.3.4.20;
>> 1.3.6.1.4.1.1466.29539.12; 2.16.840.1.113730.3.4.12;
>> 2.16.840.1.113730.3.4.18; 2.16.840.1.113730.3.4.13;
>> supportedExtension (17): 2.16.840.1.113730.3.5.7;
>> 2.16.840.1.113730.3.5.8; 2.16.840.1.113730.3.5.10;
>> 2.16.840.1.113730.3.8.10.3; 1.3.6.1.4.1.4203.1.11.1;
>> 2.16.840.1.113730.3.8.10.1; 2.16.840.1.113730.3.5.3;
>> 2.16.840.1.113730.3.5.12; 2.16.840.1.113730.3.5.5;
>> 2.16.840.1.113730.3.5.6; 2.16.840.1.113730.3.5.9;
>> 2.16.840.1.113730.3.5.4; 2.16.840.1.113730.3.6.5;
>> 2.16.840.1.113730.3.6.6; 2.16.840.1.113730.3.6.7;
>> 2.16.840.1.113730.3.6.8; 1.3.6.1.4.1.1466.20037 = ( START_TLS );
>> supportedLDAPVersion (2): 2; 3;
>> supportedSASLMechanisms (7): EXTERNAL; ANONYMOUS; PLAIN; LOGIN;
>> DIGEST-MD5; GSSAPI; CRAM-MD5;
>> vendorName: 389 Project;
>> vendorVersion: 389-Directory/1.2.11.15 <http://1.2.11.15>
>> B2013.337.1530;
>>>
>>> this is the output
>>>
>>> openssl s_client -connect qatestdc2.boingoqa.local:636
>>> CONNECTED(00000003)
>>> depth=0
>>> verify error:num=20:unable to get local issuer certificate
>>> verify return:1
>>> depth=0
>>> verify error:num=27:certificate not trusted
>>> verify return:1
>>> depth=0
>>> verify error:num=21:unable to verify the first certificate
>>> verify return:1
>>> ---
>>> Certificate chain
>>> 0 s:
>>> i:/DC=local/DC=boingoqa/CN=SKYWARPCA
>>> ---
>>> Server certificate
>>> -----BEGIN CERTIFICATE-----
>>> MIIGpzCCBI+gAwIBAgIKYTm2iQAAAAAAETANBgkqhkiG9w0BAQQFADBFMRUwEwYK
>>> CZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghib2luZ29xYTESMBAG
>>> A1UEAxMJU0tZV0FSUENBMB4XDTE0MDIwNDE5MTcxNVoXDTE2MDIwNDE5MjcxNVow
>>> ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBobXktKGUg/ynXMuQ7
>>> q4KPRHSQkU7yD6wrpC+rzbjVYyg3LyE7+STlt0TbsataBciq5DExeByJIWvDn81T
>>> RW2dqXYUhCPfH96rt6SpnZtWwLs2fBtFqnC4K7Wf7k3b3JHUiMw+V9Q6Nlo4w6HX
>>> PygYAKVp/4L+SS0S55MRRYhTPgwE6nnj1HXbJuAwyNcn/xaqI5XIoSVYwXYNkaz5
>>> 4JibJ/bJvMqwfnIQH6JuTz2YgXSdebz6UzgsloYfJlpr15UoAvkRcjtdCN+I6ZGT
>>> j9AJNhOCzqDn1M5nrwpDj6+AZjf49yXQ4MndZaCAcD3lUIZZfzBh8plBIhbR6P9l
>>> wgsCAwEAAaOCAtwwggLYMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIb+j0KF
>>> oOMAh/2TOIWXwCKG2tdBgUiB4aFdg/6GFQIBZQIBADAyBgNVHSUEKzApBgcrBgEF
>>> AgMFBgorBgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQD
>>> AgWgMEAGCSsGAQQBgjcVCgQzMDEwCQYHKwYBBQIDBTAMBgorBgEEAYI3FAICMAoG
>>> CCsGAQUFBwMBMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQ7uvQtzIM4rIkZ+9gx+qwj
>>> gGfVVTAfBgNVHSMEGDAWgBR8X3Ffa9ODPVuv2VSdfoixzqhcgzCBzAYDVR0fBIHE
>>> MIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1TS1lXQVJQQ0EsQ049UUFURVNUREMy
>>> LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD
>>> Tj1Db25maWd1cmF0aW9uLERDPWJvaW5nb3FhLERDPWxvY2FsP2NlcnRpZmljYXRl
>>> UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q
>>> b2ludDCBvgYIKwYBBQUHAQEEgbEwga4wgasGCCsGAQUFBzAChoGebGRhcDovLy9D
>>> Tj1TS1lXQVJQQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO
>>> PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Ym9pbmdvcWEsREM9bG9jYWw/
>>> Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRo
>>> b3JpdHkwQAYDVR0RAQH/BDYwNIIYUUFURVNUREMyLmJvaW5nb3FhLmxvY2Fsgg5i
>>> b2luZ29xYS5sb2NhbIIIQk9JTkdPUUEwDQYJKoZIhvcNAQEEBQADggIBALZdnAQ3
>>> Q89udt97z7fRhCEOe/169M4Veo7mxw5IJ7/kdv3+6OQr/6xXOgy67SpeEj14BPCB
>>> ehEXHd1N8nSd5MxR73C65QxiC/jCR0VhHYIZyNkGke44EWl6o/7frHHXIkgKhSHI
>>> TumCdHc1erfwlRaifPksYO8f5HpE1FABeBhmPau003My4uLbcwMPt+XS1AlGSRM7
>>> mxE3JjnFp0iD+kNvDA7SlcOYxkNRyCG1ty4TOdWq9FIRf9m+f4dLXZ/ZR2kPi7GY
>>> TBwCm4R8wqvi2UmNv2b/jhP39RqVEXMlFoVM2ciOSk5Za9zJ/0ykhHTImea92Pwz
>>> eNfF89abIR7rADkPsulcTfAuwLfHbnfB2DUw75WaIesNLyc49sjgWLSk2B0trjc8
>>> Z2FiVWYRBgLLrn5OKOHIzBD9fuGShTMU5I6U53Sr0CtoSvAX57wfkSdlydAH/MqP
>>> lFBjzGWQA00ZiEgN0Cc1y47g50uHE8nUNoeVoxD0arBO8utvr7R6yL9caIvs+09N
>>> B/idR3c8Sjb0c3g8pCFGLzDkM6iH/cklzh8hYaddbCiHzDruzbJv4ORLFo7dL/Sb
>>> nZbit2qjoLUmnTSXAxE9A39qiX5f/cKUFnFB/kuiYKUoUFaWkLxmXd9zarIhkpA6
>>> 1adEmspCvWswrfVKhgrR1ELf4qNo1nEKOsi9
>>> -----END CERTIFICATE-----
>>> subject=
>>> issuer=/DC=local/DC=boingoqa/CN=SKYWARPCA
>>> ---
>>> Acceptable client certificate CA names
>>>
>>> /DC=local/DC=boingoqa/CN=SKYWARPCA
>>> /CN=QATESTDC2.boingoqa.local
>>> /DC=local/DC=boingoqa/CN=boingoqaca
>>> /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
>>> /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
>>> /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
>>> /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048)
>>> /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
>>> /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
>>> /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
>>> /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
>>> /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
>>> /O=BOINGO.COM/CN=Certificate Authority
>>> /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority
>>> /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority
>>> /CN=NT AUTHORITY
>>> ---
>>> SSL handshake has read 3480 bytes and written 601 bytes
>>> ---
>>> New, TLSv1/SSLv3, Cipher is AES128-SHA
>>> Server public key is 2048 bit
>>> Secure Renegotiation IS supported
>>> Compression: NONE
>>> Expansion: NONE
>>> SSL-Session:
>>> Protocol : TLSv1
>>> Cipher : AES128-SHA
>>> Session-ID: 333C0000854E673466C6993943C1FBC7E65382AB7C486AFA750CB5F76D45302A
>>> Session-ID-ctx:
>>> Master-Key: 63BF2A0621C3438C7CD8A0037B3769FC9182FF517B7D07265B8EE5F74FD90BBA0B8E56B9F466F3502F32C816076DAA47
>>> Key-Arg : None
>>> Krb5 Principal: None
>>> PSK identity: None
>>> PSK identity hint: None
>>> Start Time: 1391547347
>>> Timeout : 300 (sec)
>>> Verify return code: 21 (unable to verify the first certificate)
>>> ---
>>>
>>> ------------------------------------------------------------------------
>>> *From:* freeipa-users-bounces at redhat.com
>>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh
>>> [tmaugh at boingo.com]
>>> *Sent:* Tuesday, February 04, 2014 12:53 PM
>>> *To:* Rich Megginson; dpal at redhat.com
>>> *Cc:* freeipa-users at redhat.com
>>> *Subject:* Re: [Freeipa-users] Creating password sync
>>>
>>> I tried changing the password for a user in AD
>>>
>>> this is what the passsync log shows:
>>>
>>> 02/04/14 12:29:14: Ldap bind error in Connect
>>> 81: Can't contact LDAP server
>>> 02/04/14 12:49:34: Ldap bind error in Connect
>>> 81: Can't contact LDAP server
>>> 02/04/14 12:49:34: Ldap error in QueryUsername
>>> 81: Can't contact LDAP server
>>> 02/04/14 12:49:36: Ldap bind error in Connect
>>> 81: Can't contact LDAP server
>>> 02/04/14 12:49:36: Ldap error in QueryUsername
>>> 81: Can't contact LDAP server
>>>
>>>
>>> and you say this is one of many issues with passsync. do you
>>> recommend another option?
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Todd Maugh
>>> *Sent:* Tuesday, February 04, 2014 12:48 PM
>>> *To:* Rich Megginson; dpal at redhat.com
>>> *Cc:* freeipa-users at redhat.com
>>> *Subject:* RE: Creating password sync
>>>
>>> but what about the "cant contact LDAP server in the passsync log"
>>>
>>> and are you saying I should try to change one of the passwords in AD
>>> for it to go to IDM, or vice versa?
>>>
>>> thanks
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>> *Sent:* Tuesday, February 04, 2014 12:45 PM
>>> *To:* Todd Maugh; dpal at redhat.com
>>> *Cc:* freeipa-users at redhat.com
>>> *Subject:* Re: Creating password sync
>>>
>>> On 02/04/2014 01:42 PM, Todd Maugh wrote:
>>>> I have not changed any passwords in AD yet.
>>>
>>> Then passsync will not have sent anything.
>>>
>>>>
>>>> and the users I have in IDM from AD, their passwords are not working
>>>
>>> Right. This is one of the (many) problems with the passsync
>>> approach - there currently is no way to populate the initial
>>> passwords - that is, passsync/IdM cannot copy your passwords over
>>> from AD to IdM.
>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>>> *Sent:* Tuesday, February 04, 2014 12:40 PM
>>>> *To:* Todd Maugh; dpal at redhat.com
>>>> *Cc:* freeipa-users at redhat.com
>>>> *Subject:* Re: Creating password sync
>>>>
>>>> On 02/04/2014 01:20 PM, Todd Maugh wrote:
>>>>> my passhook.log file is empty
>>>>
>>>> Have you changed any passwords in AD?
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From:* freeipa-users-bounces at redhat.com
>>>>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh
>>>>> [tmaugh at boingo.com]
>>>>> *Sent:* Tuesday, February 04, 2014 11:56 AM
>>>>> *To:* Rich Megginson; dpal at redhat.com
>>>>> *Cc:* freeipa-users at redhat.com
>>>>> *Subject:* Re: [Freeipa-users] Creating password sync
>>>>>
>>>>> Im seeing these errors in the passsync.log
>>>>>
>>>>> 32: No such object
>>>>> 02/03/14 16:23:40: Ldap error in QueryUsername
>>>>> 32: No such object
>>>>> 02/03/14 16:57:48: Abandoning password change for scottb, backoff
>>>>> expired
>>>>> 02/03/14 16:57:48: Ldap bind error in Connect
>>>>> 32: No such object
>>>>> 02/03/14 16:57:48: Ldap error in QueryUsername
>>>>> 32: No such object
>>>>> 02/03/14 18:06:04: Abandoning password change for scottb, backoff
>>>>> expired
>>>>> 02/03/14 18:06:04: Ldap bind error in Connect
>>>>> 32: No such object
>>>>> 02/04/14 10:24:59: PassSync service initialized
>>>>> 02/04/14 10:24:59: PassSync service running
>>>>> 02/04/14 10:25:00: Ldap bind error in Connect
>>>>> 32: No such object
>>>>> 02/04/14 10:58:37: Ldap bind error in Connect
>>>>> 32: No such object
>>>>> 02/04/14 10:58:37: PassSync service stopped
>>>>> 02/04/14 10:58:38: PassSync service initialized
>>>>> 02/04/14 10:58:38: PassSync service running
>>>>> 02/04/14 10:58:39: Ldap bind error in Connect
>>>>> 32: No such object
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>>>> *Sent:* Tuesday, February 04, 2014 9:19 AM
>>>>> *To:* Todd Maugh; dpal at redhat.com
>>>>> *Cc:* freeipa-users at redhat.com
>>>>> *Subject:* Re: Creating password sync
>>>>>
>>>>> On 02/04/2014 10:17 AM, Todd Maugh wrote:
>>>>>> also I have verified the password synchronization service is
>>>>>> started and running on the windows 2008 R2 server
>>>>>>
>>>>>>
>>>>>> but I cant tell if or what it is doing because iM not getting
>>>>>> passwords to my IDM
>>>>> http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging
>>>>>
>>>>> You can also look at the 389 access log to see if you have
>>>>> connections from the windows box.
>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> *From:* freeipa-users-bounces at redhat.com
>>>>>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh
>>>>>> [tmaugh at boingo.com]
>>>>>> *Sent:* Tuesday, February 04, 2014 9:04 AM
>>>>>> *To:* Rich Megginson; dpal at redhat.com
>>>>>> *Cc:* freeipa-users at redhat.com
>>>>>> *Subject:* [Freeipa-users] Creating password sync
>>>>>>
>>>>>> Ok, So I have my replication agreement set up.
>>>>>>
>>>>>> and I see accounts coming in to my IDM server from AD
>>>>>>
>>>>>> I have followed this guide from redhat
>>>>>>
>>>>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html
>>>>>>
>>>>>> to set up my password sync.
>>>>>>
>>>>>> I get no errors
>>>>>>
>>>>>> but my passwords are not syncing!
>>>>>>
>>>>>> Help! the documentation tells o fno way to verify or trouble shoot
>>>>>>
>>>>>>
>>>>>> Thank You
>>>>>>
>>>>>> -Todd Maugh
>>>>>> tmaugh at boingo.com
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140204/845bd282/attachment.htm>
More information about the Freeipa-users
mailing list