Re: [Freeipa-users] "Could not locate issuing CA" when querying OCSP responder

2016-07-26 Thread Fraser Tweedale 
On Tue, Jul 26, 2016 at 05:16:34AM -0500, Anthony Joseph Messina wrote:
> On Tuesday, July 26, 2016 2:40:38 PM CDT Fraser Tweedale wrote:
> > On Tue, Jul 26, 2016 at 01:45:19PM +1000, Fraser Tweedale wrote:
> > > On Mon, Jul 25, 2016 at 05:23:31PM -0500, Anthony Joseph Messina wrote:
> > > > After upgrading to FreeIPA 4.3.1, I am getting "Error querying OCSP
> > > > responder" with the following command.  I can confirm certificate with
> > > > serial 0x14 is present in the system and is not expired/revoked, etc. 
> > > > I'm a bit nervous about the "OCSPServlet: Could not locate issuing CA"
> > > > in the Dogtag output below.
> > > > 
> > > > # /usr/bin/openssl ocsp \
> > > > 
> > > >   -issuer /etc/ipa/ca.crt \
> > > >   -nonce \
> > > >   -CAfile /etc/ipa/ca.crt \
> > > >   -url "http://ipa-ca.example.com/ca/ocsp; \
> > > >   -serial 0x14
> > > > 
> > > > # rpm -q freeipa-server pki-server
> > > > freeipa-server-4.3.1-1.fc24.x86_64
> > > > pki-server-10.3.3-1.fc24.noarch
> > > 
> > > Hi Anthony,
> > > 
> > > I wrote this code and I think I know what the issue is.  Could you
> > > please execute `pki-server db-upgrade -v` as root, then try the OCSP
> > > request again?
> > > 
> > > If it works, happy day for you, and for me too because it confirms
> > > the issue which I must fix :)
> > 
> > On further investigation, what I thought was the problem cannot be
> > the problem.  No need to follow my earlier suggestion.
> > 
> > But I found (and fixed) something else.  Would you be willing to try
> > my COPR build[1]?  It contains the linked patch[2] plus whatever is
> > between your installed pki version and the Dogtag master branch at
> > a307cf68e91327ddbef4b9d7e2bbd3991354831f.
> > 
> > [1] https://copr.fedorainfracloud.org/coprs/ftweedal/freeipa/build/420751/
> > [2]
> > https://fedorahosted.org/pki/attachment/ticket/2420/pki-ftweedal-0128-Fix-C
> > A-OCSP-responder-when-LWCAs-are-not-in-use.patch
> > 
> > Alternatively, you can apply the patch and build Dogtag yourself
> > (if, e.g., you do not trust my COPR packages, which is fair enough
> > ^_^)
> 
> Your COPR repo with this patch fixes the OCSP responder issue.  Thank you 
> Fraser. -A
> 
Thank you for testing!  Patch will now be reviewed by Dogtag team
and hopefully we can get an official build out soon.

Cheers,
Fraser

-- 
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

Re: [Freeipa-users] Replica install fails when using --setup-ca

2016-07-26 Thread Rob Crittenden 

Linov Suresh wrote:

I tried to create master replica using the option --setup-ca, it failed,
because of "Your system may be partly configured."

Please note we use different ipa package for master and replica.

master:
[root@caer ~]# rpm -q ipa-server
ipa-server-3.0.0-26.el6_4.2.x86_64

replica:

[root@neit-lab01 ~]# rpm -q ipa-server
ipa-server-3.0.0-50.el6.1.x86_64

*Is this because ipa-server-3.0.0-50 has updates feature "Proxy calls to
/ca/ee/ca/profileSubmit to PKI to enable installation of replicas with
Dogtag 10 PKI (#1083878)"*
*
*
If yes, how do we fix it? Your help is appreciated.


[root@neit-lab01 ipa]#*ipa-replica-install --setup-dns --setup-ca
--no-forwarders /var/lib/ipa/replica-info-neit-lab01.teloip.net.gpg*
Directory Manager (existing master) password:

Run connection check to master
Check connection from replica to remote master 'caer.teloip.net
':
Directory Service: Unsecure port (389): OK
Directory Service: Secure port (636): OK
Kerberos KDC: TCP (88): OK
Kerberos Kpasswd: TCP (464): OK
HTTP Server: Unsecure port (80): OK
HTTP Server: Secure port (443): OK
PKI-CA: Directory Service port (7389): OK

The following list of ports use UDP protocol and would need to be
checked manually:
Kerberos KDC: UDP (88): SKIPPED
Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
ad...@teloip.net  password:

Execute check on remote master
Check connection from master to remote replica 'neit-lab01.teloip.net
':
Directory Service: Unsecure port (389): OK
Directory Service: Secure port (636): OK
Kerberos KDC: TCP (88): OK
Kerberos KDC: UDP (88): OK
Kerberos Kpasswd: TCP (464): OK
Kerberos Kpasswd: UDP (464): OK
HTTP Server: Unsecure port (80): OK
HTTP Server: Secure port (443): OK
PKI-CA: Directory Service port (7389): OK

Connection from master to replica is OK.

Connection check OK
Configuring NTP daemon (ntpd)
   [1/4]: stopping ntpd
   [2/4]: writing configuration
   [3/4]: configuring ntpd to start on boot
   [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server for the CA (pkids): Estimated time 30 seconds
   [1/3]: creating directory server user
   [2/3]: creating directory server instance
   [3/3]: restarting directory server
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30
seconds
   [1/17]: creating certificate server user
   [2/17]: creating pki-ca instance
   [3/17]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
neit-lab01.teloip.net  -cs_port 9445
-client_certdb_dir /tmp/tmp-t5u9YQ -client_certdb_pwd 
-preop_pin BAoCQwvMxnG4xLdxOKln -domain_name IPA -admin_user admin
-admin_email root@localhost -admin_password  -agent_name
ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa
-agent_cert_subject CN=ipa-ca-agent,O=TELOIP.NET 
-ldap_host neit-lab01.teloip.net 
-ldap_port 7389 -bind_dn cn=Directory Manager -bind_password 
-base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa
-key_algorithm SHA256withRSA -save_p12 true -backup_pwd 
-subsystem_name pki-cad -token_name internal
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=TELOIP.NET
 -ca_subsystem_cert_subject_name CN=CA
Subsystem,O=TELOIP.NET  -ca_ocsp_cert_subject_name
CN=OCSP Subsystem,O=TELOIP.NET 
-ca_server_cert_subject_name CN=neit-lab01.teloip.net
,O=TELOIP.NET 
-ca_audit_signing_cert_subject_name CN=CA Audit,O=TELOIP.NET
 -ca_sign_cert_subject_name CN=Certificate
Authority,O=TELOIP.NET  -external false -clone true
-clone_p12_file ca.p12 -clone_p12_password  -sd_hostname
caer.teloip.net  -sd_admin_port 443
-sd_admin_name admin -sd_admin_password  -clone_start_tls true
-clone_uri https://caer.teloip.net:443' returned non-zero exit status 255

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Configuration of CA failed




You need to look at the dogtag logs to see any reasonable errors. IPA 
doesn't get much back from the dogtag installer except a pass/fail 
(especially in 3.x).


rob

--
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

Re: [Freeipa-users] IPA certificates expired, please help!

2016-07-26 Thread Rob Crittenden 

Linov Suresh wrote:

Removed the duplicate certificates and and tried to renew the
certificates, we were able to renew the certificates and "*ca-error:
Internal error: no response to
"http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=63=true=true"*.;
gone this time.

Thanks for your help. We have a master replica also, *how do we renew
the replica server*?


Pretty much the same way: go back in time.

If you have a CA on this other master then it can fetch the subsystem 
certs directly from LDAP so that should pretty much work no matter what 
the current date is.


For the certs for 389-ds and Apache you'll probably need to go back in 
time to when they are still valid.


rob



On Fri, Jul 22, 2016 at 3:36 PM, Linov Suresh > wrote:

Thank you very much Rob.
Let me remove the duplicate certificates and try to renew the
certificates again to see if "*ca-error: Internal error: no response
to

"http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=63=true=true"*.;
goes away?


On Fri, Jul 22, 2016 at 2:45 PM, Rob Crittenden > wrote:

Linov Suresh wrote:

Could you please verify, if we have set correct trust
attributes on the
certificates

*root@caer ~]# certutil -d /var/lib/pki-ca/alias/ -L*

Certificate Nickname
  Trust
Attributes

   SSL,S/MIME,JAR/XPI

subsystemCert cert-pki-ca
  u,u,Pu
ocspSigningCert cert-pki-ca
  u,u,u
caSigningCert cert-pki-ca
  CTu,Cu,Cu
subsystemCert cert-pki-ca
  u,u,Pu
Server-Cert cert-pki-ca
u,u,u
auditSigningCert cert-pki-ca
   u,u,Pu
*
*
*[root@caer ~]# certutil -d /etc/httpd/alias/ -L*

Certificate Nickname
  Trust
Attributes

   SSL,S/MIME,JAR/XPI

ipaCert
u,u,u
Server-Certu,u,u
TELOIP.NET   IPA CA
   CT,C,C
ipaCert
u,u,u
Signing-Cert   u,u,u
Server-Certu,u,u

*[root@caer ~]# certutil -d /etc/dirsrv/slapd-TELOIP-NET/ -L*

Certificate Nickname
  Trust
Attributes

   SSL,S/MIME,JAR/XPI

Server-Cert
u,u,u
TELOIP.NET   IPA CA
   CT,,C
Server-Cert
u,u,u
[root@caer ~]#

*Please note, there are duplicate certificates in CA, HTTP
and LDAP
directory, subsystemCert cert-pki-ca, ipaCert  and
Server-Cert. I was
wondering if we need to remove these duplicate certificates? *


Yeah you should remove the duplicate certs, they seem to cause
problems with dogtag at least (certmonger _should_ handle this
automatically, we'll be looking into it soonish).

To remove the duplicate cert:

1. Shutdown the service
2. Back up the NSS database
3. certutil -L -d /path/to/db -n  -a > somefile
4. split somefile into separate files so each file as a
BEGIN/END certificate
5. openssl x509 -text -in -infile somefile1..n
6. Pick the one with the most recent issuance date
7. You backed up the NSS database, right?
8. certutil -D -d /path/to/db -n 
9. certutil -A -d /path/to/db -n  -t u,u,u -a -i
somefilex
10. Start the service, watch logs for errors

For the trust use whatever the original trust value was.

You don't need the P trust flag on the subsystemCert in the CA,
only the auditSigningCert.

I doubt the duplicated Server-Cert will be a problem. NSS is
supposed to deal with this automatically, picking the "most
correct" cert to use based on the validity period.

rob



On Fri, Jul 22, 2016 at 9:36 AM, Linov Suresh

>> wrote:

 I'm facing another issue now, my kerberos tickets are
not renewing,

 *[root@caer ~]# ipa cert-show 1*
 ipa: ERROR: Ticket expired

 *[root@caer ~]# klist*
 Ticket cache: FILE:/tmp/krb5cc_0
 Default principal: ad...@teloip.net

Re: [Freeipa-users] Deny bind for external LDAP if password is expired

2016-07-26 Thread Rob Crittenden 

Prashant Bapat wrote:

In our FreeIPA deployment the clients use pam_nss_ldapd with the
"compat" schema. No ipa-client.

I'm planning to apply the patched ipa_pwd_extop plugin to only 2 of the
replicas (out of 8) where the external app authenticates against IPA's
LDAP. These 2 replicas are more used like readonly. The Web UI where the
users login and change their profile is not on these replicas.

With this LDAP binds are denied to users with expired passwords from the
external app.

Will this setup have any issues, related to replication etc ?


I don't think it will cause any replication issues. You may want to 
remove them from the SRV entries if you have one. Clients outside of 
your external apps could end up connecting to them through autodiscovery 
otherwise (and maybe that's ok, up to you).


rob



On 11 July 2016 at 19:43, Rob Crittenden > wrote:

Prashant Bapat wrote:

I cherrypicked the commit id
3b7d5e7543a074d7d24556cadc6c95be9871cfc6
and compiled the ipa-pwd-extop slapi plugin.

Now the user is denied bind. But unable to reset the password.


Right, it's a tricky problem which is why it hasn't been resolved
yet. You have come full circle through the same steps we went through.

rob



On 8 July 2016 at 13:21, Martin Kosek 
>> wrote:

 On 07/07/2016 05:19 PM, Prashant Bapat wrote:
 > Anyone ?!
 >
 > On 6 July 2016 at 22:36, Prashant Bapat

>
 > 

 > Hi,
 >
 > We are using FreeIPA's LDAP as the base for user
authentication in a
 > different application. So far I have created a
sysaccount which does the
 > lookup etc for a user and things are working as
expected. I'm even able to
 > use OTP from the external app.
 >
 > One problem I'm struggling to fix is the expired
passwords. Is there a way
 > to deny bind to LDAP only from this application?
Obviously the user would
 > need to go to IPA's web UI and reset his password there.
 >
 > I came across this
tickethttps://fedorahosted.org/freeipa/ticket/1539
 but
 > looks like this is an old one.
 >
 > Thanks.
 > --Prashant

 Hello Prashant,

https://fedorahosted.org/freeipa/ticket/1539 seems to be the right
 ticket, if
 you want users with expired passwords to be denied, but it
was not
 implemented
 yet. Help welcome!

 As a workaround, I assume you could simply leverage
Kerberos for
 authentication
 - it does respect expired passwords. We have advise on how to
 integrate that to
 external web applications here:

http://www.freeipa.org/page/Web_App_Authentication

 Martin








--
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

Re: [Freeipa-users] AD trust with POSIX attributes

2016-07-26 Thread Justin Stephenson 
As Alexander mentioned, the LDAP schema still exists to add POSIX 
attributes to users and groups in AD but IDMU simply provides a 
convenient Graphical interface to manage this. You should still be able 
to use powershell or other windows tools to modify POSIX attributes 
going forward, but in general a lot of users are moving towards sssd 
automatic ID mapping which means there is no administrative management 
of uid/gid values.


There may be some other purpose for IDMU that I am not aware of...

Kind regards,

Justin Stephenson

On 07/25/2016 10:54 AM, Jan Karásek wrote:

Hi,

just for the clarification:

Do I really need IDMU on AD side installed for IPA-AD trust with 
-range-type=ipa-ad-trust-posix ? In W2012 all POSIX attributes are 
already in schema and idrange type can be forced. I just tried to 
remove IDMU from my AD and it's still working. What is the role of 
IDMU other than allowing to autodetect POSIX idrange type via 
the msSFU30OrderNumber msSFU30MaxUidNumber attributes ?


Regards,
Jan


*From: *"Jan Karásek" 
*To: *"Justin Stephenson" 
*Cc: *"Alexander Bokovoy" , freeipa-users@redhat.com
*Sent: *Friday, July 22, 2016 3:19:51 PM
*Subject: *Re: [Freeipa-users] AD trust with POSIX attributes

Hi,

thanks a lot for help guys. It's working now. I can successfully read 
POSIX attributes from AD.


Just now I'am storring uidNumber, gidNumber, gecos, loginShell and 
unixHomeDirectory in AD.


I have trouble with homedir. It's using subdomain_homedir from 
sssd.conf and not reflecting the value of unixHomeDirectory attribute.


Is there any way to use value from AD not from subdomain_homedir 
template for this parameter ?


Regards,
Jan

*From: *"Justin Stephenson" 
*To: *"Jan Karásek" , "Alexander Bokovoy" 


*Cc: *freeipa-users@redhat.com
*Sent: *Thursday, July 21, 2016 3:54:25 PM
*Subject: *Re: [Freeipa-users] AD trust with POSIX attributes

Hello,

You should remove the following from sssd.conf:

/[domain/example.tt]//
//debug_level = 7//
//ldap_id_mapping = False//
//id_provider = ad/

With the AD trust configuration, you do not need to specify any 
additional domain because IPA will contact AD across the trust using 
the external and POSIX groups you created during the trust setup.


Once done try restarting sssd and removing the /var/lib/sss/db/* cache

Kind regards,
Justin Stephenson

On 07/21/2016 07:56 AM, Jan Karásek wrote:

Thank you.

Now I have IDMU installed and when creating trust, IPA is
correctly autodetecting the range type:

Range name: EXAMPLE.TT_id_range
  First Posix ID of the range: 1
  Number of IDs in the range: 20
  Domain SID of the trusted domain:
S-1-5-21-4123312533-990676102-3576722756
  Range type: Active Directory trust range with POSIX attributes

When asking for uid of the AD user:

[root@ipa1 sssd]# id us...@example.tt
uid=1392001119(us...@example.tt) gid=1392001119(us...@example.tt)
groups=1392001119(us...@example.tt),1392000513(domain
us...@example.tt),97907(external_users)


... so ID-mapping is still in action.

According to doc:

To use existing POSIX attributes, two things must be configured:

 *
The POSIX attributes must be published to Active Directory's
global catalog. - done with  uidNumber,  gidNumber
 *
ID mapping (|ldap_id_mapping| in the Active Directory domain
entry) must be disabled in SSSD. - done

Here is my sssd.conf from IPA server. Is there anything else I
should do to switch off ID-mapping ?

[domain/a.example.tt]
debug_level = 7
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = a.example.tt
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ipa1.a.example.tt
chpass_provider = ipa
ipa_server = ipa1.a.example.tt
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
#subdomain_inherit = ldap_user_principal
#ldap_user_principal = nosuchattribute

[domain/example.tt]
debug_level = 7
ldap_id_mapping = False
id_provider = ad

[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2
domains = a.example.tt, example.tt

[nss]
#debug_level = 5
#homedir_substring = /home
enum_cache_timeout = 2
entry_negative_timeout = 2


[pam]
#debug_level = 5
[sudo]

[autofs]

[ssh]
#debug_level = 4
[pac]

#debug_level = 4
[ifp]


Regards,
Jan

*From: *"Alexander Bokovoy" 
*To: *"Jan Karásek" 
*Cc: *"Justin

Re: [Freeipa-users] Could not find cert: Signing-Cert : File not found

2016-07-26 Thread Linov Suresh 
I was following the same documentation as IPA master for the replica for
the certificate renewal. But was unsuccessful.

Should we use "How do I manually renew Identity Management (IPA)
certificates after they have expired? (Replica IPA Server)" -
https://access.redhat.com/solutions/962373 ?

On Mon, Jul 25, 2016 at 6:17 PM, Linov Suresh 
wrote:

> We were not sure that Signing-Cert required for LDAP/Apache certificates
> renewal. Thank you very much for your update Rob. We are going to renew the
> certificates without Signing-Cert.
>
> On Mon, Jul 25, 2016 at 6:08 PM, Rob Crittenden 
> wrote:
>
>> Linov Suresh wrote:
>>
>>> We are using CentOS 6.4/FreeIPA 3.0.0
>>>
>>> LDAP/Apache certificates were expired and when we tried to renew, we
>>> found Signing-Cert is missing.
>>>
>>> # certutil -L -d /etc/httpd/alias -n Signing-Cert certutil: Could not
>>> find cert: Signing-Cert : File not found
>>>
>>> How do we recreate Signing-Cert certificate? We use master-master
>>> replica. Please help.
>>>
>>>
>>>
>> Only the initial master got a signing cert IIRC. It was used to sign the
>> Firefox configuration jar. Are you using this? Recent versions of Firefox
>> don't allow this kind of signed jar anymore and it has been dropped
>> upstream.
>>
>> Are you just trying to be thorough or is this causing some real problem?
>>
>> rob
>>
>
>
-- 
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

[Freeipa-users] Replica install fails when using --setup-ca

2016-07-26 Thread Linov Suresh 
I tried to create master replica using the option --setup-ca, it failed,
because of "Your system may be partly configured."

Please note we use different ipa package for master and replica.

master:
[root@caer ~]# rpm -q ipa-server
ipa-server-3.0.0-26.el6_4.2.x86_64

replica:

[root@neit-lab01 ~]# rpm -q ipa-server
ipa-server-3.0.0-50.el6.1.x86_64

*Is this because ipa-server-3.0.0-50 has updates feature "Proxy calls to
/ca/ee/ca/profileSubmit to PKI to enable installation of replicas with
Dogtag 10 PKI (#1083878)"*

If yes, how do we fix it? Your help is appreciated.


[root@neit-lab01 ipa]#* ipa-replica-install --setup-dns --setup-ca
--no-forwarders /var/lib/ipa/replica-info-neit-lab01.teloip.net.gpg*
Directory Manager (existing master) password:

Run connection check to master
Check connection from replica to remote master 'caer.teloip.net':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK
   PKI-CA: Directory Service port (7389): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
ad...@teloip.net password:

Execute check on remote master
Check connection from master to remote replica 'neit-lab01.teloip.net':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK
   PKI-CA: Directory Service port (7389): OK

Connection from master to replica is OK.

Connection check OK
Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server for the CA (pkids): Estimated time 30 seconds
  [1/3]: creating directory server user
  [2/3]: creating directory server instance
  [3/3]: restarting directory server
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30
seconds
  [1/17]: creating certificate server user
  [2/17]: creating pki-ca instance
  [3/17]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
neit-lab01.teloip.net -cs_port 9445 -client_certdb_dir /tmp/tmp-t5u9YQ
-client_certdb_pwd  -preop_pin BAoCQwvMxnG4xLdxOKln -domain_name
IPA -admin_user admin -admin_email root@localhost -admin_password 
-agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa
-agent_cert_subject CN=ipa-ca-agent,O=TELOIP.NET -ldap_host
neit-lab01.teloip.net -ldap_port 7389 -bind_dn cn=Directory Manager
-bind_password  -base_dn o=ipaca -db_name ipaca -key_size 2048
-key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd
 -subsystem_name pki-cad -token_name internal
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=TELOIP.NET
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=TELOIP.NET
-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=TELOIP.NET
-ca_server_cert_subject_name CN=neit-lab01.teloip.net,O=TELOIP.NET
-ca_audit_signing_cert_subject_name CN=CA Audit,O=TELOIP.NET
-ca_sign_cert_subject_name CN=Certificate Authority,O=TELOIP.NET -external
false -clone true -clone_p12_file ca.p12 -clone_p12_password 
-sd_hostname caer.teloip.net -sd_admin_port 443 -sd_admin_name admin
-sd_admin_password  -clone_start_tls true -clone_uri
https://caer.teloip.net:443' returned non-zero exit status 255

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Configuration of CA failed
-- 
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

[Freeipa-users] ipa-adtrust-install failing at samba restart

2016-07-26 Thread Rolf Brusletto 
I've been following the doc here:
https://www.freeipa.org/page/Active_Directory_trust_setup

To get AD Trust setup for auth of our windows users and vice-versae.

I'm getting to the point of running ipa-adtrust-install and getting the
following:


[root@awse-util1 ~]# ipa-adtrust-install --netbios-name=

The log file for this installation can be found in
/var/log/ipaserver-install.log
==
This program will setup components needed to establish trust to AD domains
for
the IPA Server.

This includes:
  * Configure Samba
  * Add trust related objects to IPA LDAP server

To accept the default shown in brackets, press the Enter key.

IPA generated smb.conf detected.
Overwrite smb.conf? [no]: yes
Do you want to enable support for trusted domains in Schema Compatibility
plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work
with trusted users.

Enable trusted domains support in slapi-nis? [no]: yes

Configuring cross-realm trusts for IPA server requires password for user
'admin'.
This user is a regular system account used for IPA server administration.

admin password:


WARNING: 52 existing users or groups do not have a SID identifier assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin generate
the SID identifier for all these users. Please note, the in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1) man
page
for details.

Do you want to run the ipa-sidgen task? [no]: yes

The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Configuring CIFS
  [1/23]: stopping smbd
  [2/23]: creating samba domain object
Samba domain object already exists
  [3/23]: creating samba config registry
  [4/23]: writing samba config file
  [5/23]: adding cifs Kerberos principal
  [6/23]: adding cifs and host Kerberos principals to the adtrust agents
group
  [7/23]: check for cifs services defined on other replicas
  [8/23]: adding cifs principal to S4U2Proxy targets
cifs principal already targeted, nothing to do.
  [9/23]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
  [10/23]: adding RID bases
RID bases already set, nothing to do
  [11/23]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [12/23]: activating CLDAP plugin
CLDAP plugin already configured, nothing to do
  [13/23]: activating sidgen task
Sidgen task plugin already configured, nothing to do
  [14/23]: configuring smbd to start on boot
  [15/23]: adding special DNS service records
  [16/23]: enabling trusted domains support for older clients via Schema
Compatibility plugin
  [17/23]: restarting Directory Server to take MS PAC and LDAP plugins
changes into account
  [18/23]: adding fallback group
Fallback group already set, nothing to do
  [19/23]: adding Default Trust View
Default Trust View already exists.
  [20/23]: setting SELinux booleans
  [21/23]: enabling oddjobd
  [22/23]: starting CIFS services
ipa : CRITICAL CIFS services failed to start
  [23/23]: adding SIDs to existing users and groups
ipa : CRITICAL Failed to load ipa-sidgen-task-run.ldif: Command
''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpiM6PLp' '-H'
'ldapi://%2fvar%2frun%2fslapd-GLPTRADING-NET.socket' '-Y' 'EXTERNAL''
returned non-zero exit status 1
Done configuring CIFS.

=
Setup complete

You must make sure these network ports are open:
TCP Ports:
  * 138: netbios-dgm
  * 139: netbios-ssn
  * 445: microsoft-ds
UDP Ports:
  * 138: netbios-dgm
  * 139: netbios-ssn
  * 389: (C)LDAP
  * 445: microsoft-ds

=


As well, if I run it with the default settings smbd doesn't start either.

[root@awse-util1 ~]# ipa-adtrust-install --netbios-name=

The log file for this installation can be found in
/var/log/ipaserver-install.log
==
This program will setup components needed to establish trust to AD domains
for
the IPA Server.

This includes:
  * Configure Samba
  * Add trust related objects to IPA LDAP server

To accept the default shown in brackets, press the Enter key.

IPA generated smb.conf detected.
Overwrite smb.conf? [no]: yes
Do you want to enable support for trusted domains in Schema Compatibility
plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work
with trusted users.

Enable trusted domains support in slapi-nis? [no]:

Configuring cross-realm trusts for IPA server requires password for user
'admin'.
This user is a regular system account used for IPA server administration.

admin password:


WARNING: 52 existing users or groups do not have a SID identifier assigned.

[Freeipa-users] ipa-adtrust-install failing at samba restart

2016-07-26 Thread Rolf Brusletto 
I've been following the doc here:
https://www.freeipa.org/page/Active_Directory_trust_setup

To get AD Trust setup for auth of our windows users and vice-versae.

I'm getting to the point of running ipa-adtrust-install and getting the
following:


[root@awse-util1 ~]# ipa-adtrust-install --netbios-name=

The log file for this installation can be found in
/var/log/ipaserver-install.log
==
This program will setup components needed to establish trust to AD domains
for
the IPA Server.

This includes:
  * Configure Samba
  * Add trust related objects to IPA LDAP server

To accept the default shown in brackets, press the Enter key.

IPA generated smb.conf detected.
Overwrite smb.conf? [no]: yes
Do you want to enable support for trusted domains in Schema Compatibility
plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work
with trusted users.

Enable trusted domains support in slapi-nis? [no]: yes

Configuring cross-realm trusts for IPA server requires password for user
'admin'.
This user is a regular system account used for IPA server administration.

admin password:


WARNING: 52 existing users or groups do not have a SID identifier assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin generate
the SID identifier for all these users. Please note, the in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1) man
page
for details.

Do you want to run the ipa-sidgen task? [no]: yes

The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Configuring CIFS
  [1/23]: stopping smbd
  [2/23]: creating samba domain object
Samba domain object already exists
  [3/23]: creating samba config registry
  [4/23]: writing samba config file
  [5/23]: adding cifs Kerberos principal
  [6/23]: adding cifs and host Kerberos principals to the adtrust agents
group
  [7/23]: check for cifs services defined on other replicas
  [8/23]: adding cifs principal to S4U2Proxy targets
cifs principal already targeted, nothing to do.
  [9/23]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
  [10/23]: adding RID bases
RID bases already set, nothing to do
  [11/23]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [12/23]: activating CLDAP plugin
CLDAP plugin already configured, nothing to do
  [13/23]: activating sidgen task
Sidgen task plugin already configured, nothing to do
  [14/23]: configuring smbd to start on boot
  [15/23]: adding special DNS service records
  [16/23]: enabling trusted domains support for older clients via Schema
Compatibility plugin
  [17/23]: restarting Directory Server to take MS PAC and LDAP plugins
changes into account
  [18/23]: adding fallback group
Fallback group already set, nothing to do
  [19/23]: adding Default Trust View
Default Trust View already exists.
  [20/23]: setting SELinux booleans
  [21/23]: enabling oddjobd
  [22/23]: starting CIFS services
ipa : CRITICAL CIFS services failed to start
  [23/23]: adding SIDs to existing users and groups
ipa : CRITICAL Failed to load ipa-sidgen-task-run.ldif: Command
''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpiM6PLp' '-H'
'ldapi://%2fvar%2frun%2fslapd-GLPTRADING-NET.socket' '-Y' 'EXTERNAL''
returned non-zero exit status 1
Done configuring CIFS.

=
Setup complete

You must make sure these network ports are open:
TCP Ports:
 * 138: netbios-dgm
 * 139: netbios-ssn
 * 445: microsoft-ds
UDP Ports:
 * 138: netbios-dgm
 * 139: netbios-ssn
 * 389: (C)LDAP
 * 445: microsoft-ds

=


As well, if I run it with the default settings smbd doesn't start either.

[root@awse-util1 ~]# ipa-adtrust-install --netbios-name=

The log file for this installation can be found in
/var/log/ipaserver-install.log
==
This program will setup components needed to establish trust to AD domains
for
the IPA Server.

This includes:
  * Configure Samba
  * Add trust related objects to IPA LDAP server

To accept the default shown in brackets, press the Enter key.

IPA generated smb.conf detected.
Overwrite smb.conf? [no]: yes
Do you want to enable support for trusted domains in Schema Compatibility
plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work
with trusted users.

Enable trusted domains support in slapi-nis? [no]:

Configuring cross-realm trusts for IPA server requires password for user
'admin'.
This user is a regular system account used for IPA server administration.

admin password:


WARNING: 52 existing users or groups do not have a SID identifier assigned.
Installer

Re: [Freeipa-users] IPA certificates expired, please help!

2016-07-26 Thread Linov Suresh 
Removed the duplicate certificates and and tried to renew the certificates,
we were able to renew the certificates and "*ca-error: Internal error: no
response to
"http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=63=true=true
"*."
gone this time.

Thanks for your help. We have a master replica also, *how do we renew the
replica server*?

On Fri, Jul 22, 2016 at 3:36 PM, Linov Suresh 
wrote:

> Thank you very much Rob.
> Let me remove the duplicate certificates and try to renew the certificates
> again to see if "*ca-error: Internal error: no response to
> "http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=63=true=true
> "*."
> goes away?
>
>
> On Fri, Jul 22, 2016 at 2:45 PM, Rob Crittenden 
> wrote:
>
>> Linov Suresh wrote:
>>
>>> Could you please verify, if we have set correct trust attributes on the
>>> certificates
>>>
>>> *root@caer ~]# certutil -d /var/lib/pki-ca/alias/ -L*
>>>
>>> Certificate Nickname Trust
>>> Attributes
>>>
>>>   SSL,S/MIME,JAR/XPI
>>>
>>> subsystemCert cert-pki-ca   u,u,Pu
>>> ocspSigningCert cert-pki-ca u,u,u
>>> caSigningCert cert-pki-ca CTu,Cu,Cu
>>> subsystemCert cert-pki-ca   u,u,Pu
>>> Server-Cert cert-pki-ca u,u,u
>>> auditSigningCert cert-pki-ca  u,u,Pu
>>> *
>>> *
>>> *[root@caer ~]# certutil -d /etc/httpd/alias/ -L*
>>>
>>> Certificate Nickname Trust
>>> Attributes
>>>
>>>   SSL,S/MIME,JAR/XPI
>>>
>>> ipaCert  u,u,u
>>> Server-Certu,u,u
>>> TELOIP.NET  IPA CA
>>>   CT,C,C
>>> ipaCert  u,u,u
>>> Signing-Cert   u,u,u
>>> Server-Certu,u,u
>>>
>>> *[root@caer ~]# certutil -d /etc/dirsrv/slapd-TELOIP-NET/ -L*
>>>
>>> Certificate Nickname Trust
>>> Attributes
>>>
>>>   SSL,S/MIME,JAR/XPI
>>>
>>> Server-Cert  u,u,u
>>> TELOIP.NET  IPA CA
>>>   CT,,C
>>> Server-Cert  u,u,u
>>> [root@caer ~]#
>>>
>>> *Please note, there are duplicate certificates in CA, HTTP and LDAP
>>> directory, subsystemCert cert-pki-ca, ipaCert  and Server-Cert. I was
>>> wondering if we need to remove these duplicate certificates? *
>>>
>>
>> Yeah you should remove the duplicate certs, they seem to cause problems
>> with dogtag at least (certmonger _should_ handle this automatically, we'll
>> be looking into it soonish).
>>
>> To remove the duplicate cert:
>>
>> 1. Shutdown the service
>> 2. Back up the NSS database
>> 3. certutil -L -d /path/to/db -n  -a > somefile
>> 4. split somefile into separate files so each file as a BEGIN/END
>> certificate
>> 5. openssl x509 -text -in -infile somefile1..n
>> 6. Pick the one with the most recent issuance date
>> 7. You backed up the NSS database, right?
>> 8. certutil -D -d /path/to/db -n 
>> 9. certutil -A -d /path/to/db -n  -t u,u,u -a -i  somefilex
>> 10. Start the service, watch logs for errors
>>
>> For the trust use whatever the original trust value was.
>>
>> You don't need the P trust flag on the subsystemCert in the CA, only the
>> auditSigningCert.
>>
>> I doubt the duplicated Server-Cert will be a problem. NSS is supposed to
>> deal with this automatically, picking the "most correct" cert to use based
>> on the validity period.
>>
>> rob
>>
>>
>>>
>>> On Fri, Jul 22, 2016 at 9:36 AM, Linov Suresh >> > wrote:
>>>
>>> I'm facing another issue now, my kerberos tickets are not renewing,
>>>
>>> *[root@caer ~]# ipa cert-show 1*
>>> ipa: ERROR: Ticket expired
>>>
>>> *[root@caer ~]# klist*
>>> Ticket cache: FILE:/tmp/krb5cc_0
>>> Default principal: ad...@teloip.net 
>>>
>>> Valid starting ExpiresService principal
>>> 07/20/16 14:42:26  07/21/16 14:42:22  krbtgt/teloip@teloip.net
>>> 
>>> 07/20/16 14:42:36  07/21/16 14:42:22
>>>   HTTP/caer.teloip@teloip.net >> >
>>> 07/21/16 11:40:15  07/21/16 14:42:22
>>>   ldap/caer.teloip@teloip.net >> >
>>>
>>> I need to manually renew the tickets every day,
>>>
>>> *[root@caer ~]# kinit

Re: [Freeipa-users] who did what on IPAv3 - auditing

2016-07-26 Thread Ernedin Zajko 
Hi Stefan,

have you seen this:
https://access.redhat.com/solutions/772563

regards,

--- Ernedin ZAJKO
 eza...@root.ba

> 340282366920938463463374607431768211456



On Tue, Jul 26, 2016 at 12:45 PM, Stefan Uygur
 wrote:
> This is the case I am after just to be more precise:
>
> https://access.redhat.com/solutions/441893
>
>
>
> It was requested 3yrs ago but no follow up so far.
>
>
>
> From: Stefan Uygur
> Sent: 26 July 2016 11:18
> To: freeipa-users@redhat.com
> Subject: who did what on IPAv3 - auditing
>
>
>
> Hi all,
>
> Still around the auditing problem with IPA, it seems the part related to
> auditing is completely missing in IPA and that is not really good.
>
>
>
> For instance, to find out who did what, who added or modified the
> permissions or users or sudo rules, etc, all this need auditing and it needs
> to be proof of concept.
>
>
>
> I don’t see IPA being very friendly with auditing part, although IPA is a
> central identity management system, which means auditing is all over IPA. I
> am surprised that this part is missing.
>
>
>
> There is a page suggests to set up central login:
> http://www.freeipa.org/page/Centralized_Logging
>
>
>
> With a combination of multiple logs, but I have checked accurately the logs,
> I still can’t find out say, who added user John Doe in date 21 July 2016 at
> 11.35.
>
>
>
> Has anybody in the list experienced or set up such solution where the IPA
> server activity is tracked down?
>
>
>
> Stefan
>
>
> --
> 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

-- 
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

Re: [Freeipa-users] who did what on IPAv3 - auditing

2016-07-26 Thread Prashant Bapat 
What we have done this as follows.

1. For all the changes, happening thru IPA APIs (either cmd line of WebUI)
you can capture these in the httpd error logs. We trigger alert emails on
important events such as new user addition etc.

2. For everything including the above, you can always enable the 389 ds
ldap audit logs. Refer to this link

.

Both these logs are sent to a central logging system for storage and
retrieval.


On 26 July 2016 at 16:15, Stefan Uygur  wrote:

> This is the case I am after just to be more precise:
>
> https://access.redhat.com/solutions/441893
>
>
>
> It was requested 3yrs ago but no follow up so far.
>
>
>
> *From:* Stefan Uygur
> *Sent:* 26 July 2016 11:18
> *To:* freeipa-users@redhat.com
> *Subject:* who did what on IPAv3 - auditing
>
>
>
> Hi all,
>
> Still around the auditing problem with IPA, it seems the part related to
> auditing is completely missing in IPA and that is not really good.
>
>
>
> For instance, to find out who did what, who added or modified the
> permissions or users or sudo rules, etc, all this need auditing and it
> needs to be proof of concept.
>
>
>
> I don’t see IPA being very friendly with auditing part, although IPA is a
> central identity management system, which means auditing is all over IPA. I
> am surprised that this part is missing.
>
>
>
> There is a page suggests to set up central login:
> http://www.freeipa.org/page/Centralized_Logging
>
>
>
> With a combination of multiple logs, but I have checked accurately the
> logs, I still can’t find out say, who added user John Doe in date 21 July
> 2016 at 11.35.
>
>
>
> Has anybody in the list experienced or set up such solution where the IPA
> server activity is tracked down?
>
>
>
> Stefan
>
> --
> 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
>
-- 
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

Re: [Freeipa-users] who did what on IPAv3 - auditing

2016-07-26 Thread Stefan Uygur 
This is the case I am after just to be more precise:
https://access.redhat.com/solutions/441893

It was requested 3yrs ago but no follow up so far.

From: Stefan Uygur
Sent: 26 July 2016 11:18
To: freeipa-users@redhat.com
Subject: who did what on IPAv3 - auditing

Hi all,
Still around the auditing problem with IPA, it seems the part related to 
auditing is completely missing in IPA and that is not really good.

For instance, to find out who did what, who added or modified the permissions 
or users or sudo rules, etc, all this need auditing and it needs to be proof of 
concept.

I don't see IPA being very friendly with auditing part, although IPA is a 
central identity management system, which means auditing is all over IPA. I am 
surprised that this part is missing.

There is a page suggests to set up central login: 
http://www.freeipa.org/page/Centralized_Logging

With a combination of multiple logs, but I have checked accurately the logs, I 
still can't find out say, who added user John Doe in date 21 July 2016 at 11.35.

Has anybody in the list experienced or set up such solution where the IPA 
server activity is tracked down?

Stefan
-- 
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

Re: [Freeipa-users] "Could not locate issuing CA" when querying OCSP responder

2016-07-26 Thread Anthony Joseph Messina 
On Tuesday, July 26, 2016 2:40:38 PM CDT Fraser Tweedale wrote:
> On Tue, Jul 26, 2016 at 01:45:19PM +1000, Fraser Tweedale wrote:
> > On Mon, Jul 25, 2016 at 05:23:31PM -0500, Anthony Joseph Messina wrote:
> > > After upgrading to FreeIPA 4.3.1, I am getting "Error querying OCSP
> > > responder" with the following command.  I can confirm certificate with
> > > serial 0x14 is present in the system and is not expired/revoked, etc. 
> > > I'm a bit nervous about the "OCSPServlet: Could not locate issuing CA"
> > > in the Dogtag output below.
> > > 
> > > # /usr/bin/openssl ocsp \
> > > 
> > >   -issuer /etc/ipa/ca.crt \
> > >   -nonce \
> > >   -CAfile /etc/ipa/ca.crt \
> > >   -url "http://ipa-ca.example.com/ca/ocsp; \
> > >   -serial 0x14
> > > 
> > > # rpm -q freeipa-server pki-server
> > > freeipa-server-4.3.1-1.fc24.x86_64
> > > pki-server-10.3.3-1.fc24.noarch
> > 
> > Hi Anthony,
> > 
> > I wrote this code and I think I know what the issue is.  Could you
> > please execute `pki-server db-upgrade -v` as root, then try the OCSP
> > request again?
> > 
> > If it works, happy day for you, and for me too because it confirms
> > the issue which I must fix :)
> 
> On further investigation, what I thought was the problem cannot be
> the problem.  No need to follow my earlier suggestion.
> 
> But I found (and fixed) something else.  Would you be willing to try
> my COPR build[1]?  It contains the linked patch[2] plus whatever is
> between your installed pki version and the Dogtag master branch at
> a307cf68e91327ddbef4b9d7e2bbd3991354831f.
> 
> [1] https://copr.fedorainfracloud.org/coprs/ftweedal/freeipa/build/420751/
> [2]
> https://fedorahosted.org/pki/attachment/ticket/2420/pki-ftweedal-0128-Fix-C
> A-OCSP-responder-when-LWCAs-are-not-in-use.patch
> 
> Alternatively, you can apply the patch and build Dogtag yourself
> (if, e.g., you do not trust my COPR packages, which is fair enough
> ^_^)

Your COPR repo with this patch fixes the OCSP responder issue.  Thank you 
Fraser. -A

-- 
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
F9B6 560E 68EA 037D 8C3D  D1C9 FF31 3BDB D9D8 99B6


signature.asc
Description: This is a digitally signed message part.
-- 
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

[Freeipa-users] who did what on IPAv3 - auditing

2016-07-26 Thread Stefan Uygur 
Hi all,
Still around the auditing problem with IPA, it seems the part related to 
auditing is completely missing in IPA and that is not really good.

For instance, to find out who did what, who added or modified the permissions 
or users or sudo rules, etc, all this need auditing and it needs to be proof of 
concept.

I don't see IPA being very friendly with auditing part, although IPA is a 
central identity management system, which means auditing is all over IPA. I am 
surprised that this part is missing.

There is a page suggests to set up central login: 
http://www.freeipa.org/page/Centralized_Logging

With a combination of multiple logs, but I have checked accurately the logs, I 
still can't find out say, who added user John Doe in date 21 July 2016 at 11.35.

Has anybody in the list experienced or set up such solution where the IPA 
server activity is tracked down?

Stefan
-- 
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

Re: [Freeipa-users] AD Sync and groups

2016-07-26 Thread Alexander Bokovoy 

On Tue, 26 Jul 2016, malo wrote:

Hello,

I am currently setting up an architecture involving FreeIPA to provide 
SSO for SSH to the servers.
I have several servers (~1500) in a few datacenters all over the world 
(North America, South America, Europe, Asia).
The idea here was to have 4 masters/replicas per datacenter, with one 
master/replica involved in a winsync replication process with our AD. 
Thus, we would not suffer network outages, slow downs or timeouts 
because each FreeIPA server would have a closer database of users 
instead of querying a long distance AD.


I've managed to setup successfully the winsync replication (after 
having trouble with replication rights).  I then turned on group 
replication :


ldapmodify -x -D "cn=directory manager" -w PASS

dn: cn=meToad.XXX.example.com,cn=replica,cn=dc\3Dipa\2Cdc\3Dff\2Cdc\3Dxxx\2Cdc\3Dexample\2Cdc\3Dcom,cn=mapping 
tree,cn=config

changetype: modify
replace: nsds7NewWinGroupSyncEnabled
nsds7NewWinGroupSyncEnabled: true


I re-initialized the replication but I have no groups.
I did a little digging and came on this : 
https://bugzilla.redhat.com/show_bug.cgi?id=1002414

Very unfortunate for me but a few things bother me.

It says "reenable" in the RFE and I also found this documentation : 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Using_Windows_Sync-Synchronizing_Groups.html


There is a difference between 389-ds winsync and FreeIPA winsync. The
latter is a simplified version that doesn't see development anymore and
is not supporting group sync because groups on IPA side are sufficiently
different from AD groups while generic 389-ds winsync plugin is not
tuned to IPA DIT.

It clearly specifies how to sync groups, which I enabled, but nothings 
happen for me.

So, my questions would be :
- Is winsync group sync still enabled ?
- If not, why and when has it been disabled ?
- Is there anyway I could reenable it, by digging into the code ?

Group sync seems a really MUST HAVE as a feature for the winsync, 
since flat hierarchy is not really useful, imho.

IPA uses flat hierarchy and has no support for non-flat DIT.

I can't consider an AD Trust architecture, It would be too dangerous 
since the network connectivity of the AD is not safe enough, I could 
not risk to block SSH access on my servers because of network lag.


Has anyone been in a similar situation ? Do you have implemented AD 
trust or winsync replication in such a large scale ?

I cannot tell about actual deployments but there are plenty deployments
with trust to AD in multiple data centers.

If you need, with FreeIPA 4.0+ you can actually proxy Kerberos
authentication via IPA servers to AD DCs and also can do offline
authentication in SSSD.
--
/ Alexander Bokovoy

--
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

[Freeipa-users] AD Sync and groups

2016-07-26 Thread malo 

Hello,

I am currently setting up an architecture involving FreeIPA to provide 
SSO for SSH to the servers.
I have several servers (~1500) in a few datacenters all over the world 
(North America, South America, Europe, Asia).
The idea here was to have 4 masters/replicas per datacenter, with one 
master/replica involved in a winsync replication process with our AD. 
Thus, we would not suffer network outages, slow downs or timeouts 
because each FreeIPA server would have a closer database of users 
instead of querying a long distance AD.


I've managed to setup successfully the winsync replication (after having 
trouble with replication rights).  I then turned on group replication :


ldapmodify -x -D "cn=directory manager" -w PASS

dn: 
cn=meToad.XXX.example.com,cn=replica,cn=dc\3Dipa\2Cdc\3Dff\2Cdc\3Dxxx\2Cdc\3Dexample\2Cdc\3Dcom,cn=mapping 
tree,cn=config

changetype: modify
replace: nsds7NewWinGroupSyncEnabled
nsds7NewWinGroupSyncEnabled: true


I re-initialized the replication but I have no groups.
I did a little digging and came on this : 
https://bugzilla.redhat.com/show_bug.cgi?id=1002414

Very unfortunate for me but a few things bother me.

It says "reenable" in the RFE and I also found this documentation : 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Using_Windows_Sync-Synchronizing_Groups.html


It clearly specifies how to sync groups, which I enabled, but nothings 
happen for me.

So, my questions would be :
- Is winsync group sync still enabled ?
- If not, why and when has it been disabled ?
- Is there anyway I could reenable it, by digging into the code ?

Group sync seems a really MUST HAVE as a feature for the winsync, since 
flat hierarchy is not really useful, imho.


I can't consider an AD Trust architecture, It would be too dangerous 
since the network connectivity of the AD is not safe enough, I could not 
risk to block SSH access on my servers because of network lag.


Has anyone been in a similar situation ? Do you have implemented AD 
trust or winsync replication in such a large scale ?



Thank your for reading me,


Have a nice day,

Nathan MALO

--
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