[Freeipa-users] Python IndexError: list index out of range with ipa-server-install --external-cert-file

[Gilbert Wilson]

Apologies ahead of time as this is my first post to the list and interaction 
with the FreeIPA project. If I should be taking this question to a different 
forum please point me in the right direction!

The error condition I’m encountering is mentioned a few times on the list, but 
the threads die off without any conclusions. The most recent mention of it that 
I could find is here:

https://www.redhat.com/archives/freeipa-users/2015-March/msg00271.html

It also looks like this has shown up as a bug that was fixed here:

https://fedorahosted.org/freeipa/ticket/4397

I’m using CentOS Linux release 7.1.1503 (Core) system running FreeIPA VERSION: 
4.1.0, API_VERSION: 2.112.

The error happens when attempting to finish an ipa-server-install using a cert 
signed by an external CA:

ipa-server-install -d --external-cert-file=/path/to/certificate.pem 
--external-cert-file=/path/to/certificate_authority.pem

The install proceeds as normal, but then when trying to create the RA 
certificate it errors out with:

ipa : DEBUGThe ipa-server-install command failed, exception: 
IndexError: list index out of range
Unexpected error - see /var/log/ipaserver-install.log for details:
IndexError: list index out of range
[root@ipa ~]# ipa : DEBUGstderr=
all/cainstance.py", line 520, in configure_instance
self.start_creation(runtime=210)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
382, in start_creation
run_step(full_msg, method)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
372, in run_step
method()

  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 
1149, in __request_ra_certificate
self.requestId = item_node[0].childNodes[0].data

ipa : DEBUGThe ipa-server-install command failed, exception: 
IndexError: list index out of range
Unexpected error - see /var/log/ipaserver-install.log for details:
IndexError: list index out of range

Unlike the bug and thread I linked to above we are not using a Windows CA. Our 
CA is based on openssl. Since I’m fairly new to FreeIPA I’m not sure what logs 
would be most helpful to troubleshoot, but my bumbling about seemed to indicate 
that the the error condition is in the server’s xml-based web api 
request/response logic. I’m not sure if the error is localized to that part of 
the system or if there’s some precondition that failed beforehand. The 
installation is left in a pretty broken/useless state. If I try to run 
`ipa-server-install -d --external-cert-file=/path/to/certificate.pem 
--external-cert-file=/path/to/certificate_authority.pem` again it instructs me 
that I have to run `ipa-server-install --external-ca` (essentially, start over 
from scratch). An aside question: is there some way to rerun the setup from 
where it broke down so that I don’t have to bother our CA admin to sign my CSR 
each time? That said, I can reliably produce this error condition and am 
willing to put in some time to do data collection to track it down, and our CA 
admin is willing to humor me for a little while! But, where do I start? What 
information would be most useful to collect?

Thanks!

Gil

Gilbert Wilson
Systems Administrator
The Omni Group
+1 206-523-4152
+1 206-523-5896 (Fax)



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
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] using wildcard cert from external CA

[Fraser Tweedale]

On Tue, Nov 03, 2015 at 06:00:52PM +, Sean Conley - US wrote:
> Sorry for the redundancy but I thought it would be better to start
> a new thread since I am really asking a different question at this
> point.
> 
> We are trying to stand up an IPA instance using real certs
> (wildcard) for our domain, so that external users get a valid cert
> when coming the the https UI.  I am trying to follow the steps
> given in this thread:
> https://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html.
> It seems no matter what I do, I end up with: "full certificate
> chain is not present in /etc/ipa/pki/example.org.p12".  Has this
> process been documented more completely anywhere?  Is this still a
> valid process?
> 
> I know that there is now an -external-ca option to
> ipa-server-install, but I have questions about the CSR process
> from my CA and they are not being very responsive.  I have also
> been told that this option would require a reseller arrangement
> potentially costing a lot of money...  we don't want to be in the
> CA business...  we just want our external users to be able to
> securely access IPA.
> 
If you only want publicly trusted certs for HTTP and LDAP you should
not use --external-ca.  The CSR generated during ipa-server-install
when that option is given is for a CA certifiate, not a server
(leaf) certificate.

For HTTP / LDAP certificate(s) FreeIPA does not generate the CSR for
you.  But it sounds like you already have your wildcard cert?  If
so, then you just need to install it using ipa-server-certinstall or
the --http_pkcs12 and/or --dirsrv_pkcs12 options in
ipa-server-install.

HTH,
Fraser

> Thanks again in advance for any assistance.
> 
> Sean
> 
> 

-- 
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] FreeIPA and Samba4

[Troels Hansen]

Hi, I got a bit further.
I fount the error, being that I had some groups from the old LDAP with gid 
aroud 500, and current ID range i IPA sat to start at 2000, which was my start 
UID on the old LDAP.

Is it possible to "reset" the base UID/GID that IPA assigns to the next user? I 
can't find it saved in the LDAP anywhere?

- On Nov 3, 2015, at 1:36 PM, Sumit Bose sb...@redhat.com wrote:

> On Tue, Nov 03, 2015 at 01:09:53PM +0100, Troels Hansen wrote:
>> Hi again, so I finally got time to look further into this.
>> 
>> This task works:
>> 
>> dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config
>> add:objectclass:top,extensibleObject
>> add:cn:$TIME-$FQDN-$LIBARCH
>> add:nsslapd-basedn:"$SUFFIX"
>> add:delay:0
>> add:ttl:3600
>> 
>> However, the task gets generated, but no output can be pulled from the task:
>> 
>> ldapsearch -D "cn=Directory Manager" -W -b
>> 'cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config'
>> Enter LDAP Password:
>> # extended LDIF
>> #
>> # LDAPv3
>> # base
>> 
>> with scope subtree
>> # filter: (objectclass=*)
>> # requesting: ALL
>> #
>> 
>> # 1446551851-kenai.casalogic.lan-64, ipa-sidgen-task, tasks, config
>> dn: 
>> cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config
>> objectClass: top
>> objectClass: extensibleObject
>> nsslapd-basedn: dc=casalogic,dc=lan
>> delay: 0
>> cn: 1446551851-kenai.casalogic.lan-64
>> ttl: 3600
>> nstaskcurrentitem: 1
>> nstasktotalitems: 1
>> nstaskexitcode: 32
>> 
>> # search result
>> search: 2
>> result: 0 Success
>> 
>> # numResponses: 2
>> # numEntries:
>> 
>> Only a exitcode 32
>> The nstaskcurrentitem and nstasktotalitems remains the same till the task
>> disappeares.
>> Any way do debug these taske further to find out which user it stops at, as 
>> it
>> looks like it detects an error at one user and stops the task?
> 
> You can activate 'Plug-in debugging' by setting the
> nsslapd-errorlog-level attribute of cn=config to 65536, see
> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting for
> details. Make sure to switch it back to 0 after running the sidgen task
> because the logging is quite expensive.
> 
> HTH
> 
> bye,
> Sumit
> 
>> 
>> - On Oct 30, 2015, at 3:19 PM, Alexander Bokovoy aboko...@redhat.com 
>> wrote:
>> 
>> > On Fri, 30 Oct 2015, Troels Hansen wrote:
>> >>
>> >>
>> >>
>> >>> I think it should be
>> >>> add:nsslapd-basedn: cn=accounts,$SUFFIX
>> >>> not
>> >>> add:basedn:"cn=accounts,$SUFFIX"
>> >>>
>> >>> this is what sidgen task expects and it returns constraint violation
>> >>> error if parameters are wrong:
>> >>>
>> >>>str = fetch_attr(e, "nsslapd-basedn", NULL);
>> >>>if (str == NULL) {
>> >>>LOG_FATAL("Missing nsslapd-basedn!\n");
>> >>>*returncode = LDAP_CONSTRAINT_VIOLATION;
>> >>>ret = SLAPI_DSE_CALLBACK_ERROR;
>> >>>goto done;
>> >>>}
>> >>>
>> >>
>> >>I think you are right.
>> >>Don't know what I have tested, but it brings me a different error, that I 
>> >>didn't
>> >>see before:
>> >>
>> >>ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: 
>> >>OPERATIONS_ERROR:
>> >>{'desc': 'Operations error'}
>> >>ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations
>> >>error:
>> >>ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The
>> >>ipa-ldap-updater command was successful
>> >>
>> >>Where did you find the source for the sidgen task? I could try  looking at 
>> >>at it
>> >>myself, but can't find it.
>> > You can check it here:
>> > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221
>> > 
>> > --
>> > / Alexander Bokovoy
>> 
>> --
>> Med venlig hilsen
>> 
>> Troels Hansen
>> 
>> Systemkonsulent
>> 
>> Casalogic A/S
>> 
>> 
>> T (+45) 70 20 10 63
>> 
>> M (+45) 22 43 71 57
>> 
>> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og
>> meget mere.
>> 
>> --
>> 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

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere.

-- 
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] using wildcard cert from external CA

[Rob Crittenden]

Sean Conley - US wrote:
> Sorry for the redundancy but I thought it would be better to start a new
> thread since I am really asking a different question at this point.
> 
> We are trying to stand up an IPA instance using real certs (wildcard)
> for our domain, so that external users get a valid cert when coming the
> the https UI.  I am trying to follow the steps given in this
> thread: 
> https://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html.
>  It seems no matter what I do, I end up with: “full certificate chain is
> not present in /etc/ipa/pki/example.org.p12”.  Has this process been
> documented more completely anywhere?  Is this still a valid process?
> 
> I know that there is now an —external-ca option to ipa-server-install,
> but I have questions about the CSR process from my CA and they are not
> being very responsive.  I have also been told that this option would
> require a reseller arrangement potentially costing a lot of money…  we
> don’t want to be in the CA business…  we just want our external users to
> be able to securely access IPA.
> 
> Thanks again in advance for any assistance.

I think you misunderstand what the external-ca option does. This
generates a CSR that you hand off to an external CA which issues a
subordinate CA certificate. This isn't what you want AFAICT.

Start reading here
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-ca-options.html

and it sounds like this is the configuration you want:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-ca-options.html#install-ca-less

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] using wildcard cert from external CA

[Sean Conley - US]

Sorry for the redundancy but I thought it would be better to start a new thread 
since I am really asking a different question at this point.

We are trying to stand up an IPA instance using real certs (wildcard) for our 
domain, so that external users get a valid cert when coming the the https UI.  
I am trying to follow the steps given in this thread: 
https://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html.  It 
seems no matter what I do, I end up with: "full certificate chain is not 
present in /etc/ipa/pki/example.org.p12".  Has this process been documented 
more completely anywhere?  Is this still a valid process?

I know that there is now an -external-ca option to ipa-server-install, but I 
have questions about the CSR process from my CA and they are not being very 
responsive.  I have also been told that this option would require a reseller 
arrangement potentially costing a lot of money...  we don't want to be in the 
CA business...  we just want our external users to be able to securely access 
IPA.

Thanks again in advance for any assistance.

Sean


-- 
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] how to chain CA certs

[Sean Conley - US]

Not sure if I should start a new thread for this, but...

I am now trying to follow the instructions given in this thread:
https://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html. I
think this configuration should work well with our deployment strategy.

I feel like I am following the steps exactly but always end up with "full
certificate chain is not present in /etc/ipa/pki/example.org.p12² during
ipa-server-install.  Have others followed this process more recently?  I
am wondering if there might have been any changes so that these steps no
longer work, or possibly there is an easier way to do this now.

I am running version: ipa-server-4.1.0-18.el7.centos.4.x86_64.


On 11/1/15, 10:40 PM, "Fraser Tweedale"  wrote:

>On Mon, Nov 02, 2015 at 01:29:48AM +, Sean Conley - US wrote:
>> Hello,
>> 
>> I am new to FreeIPA and am attempting to stand up my first
>> operational instance.  We do have a commercial wildcard
>> certificate (*.internal.example.org) that should cover the IPA
>> server itself (ipa.internal.example.org).  I used the -external-CA
>> option when running the setup and so a CSR was generated.  Since
>> we have a wildcard cert, I wasn't sure if I really need to submit
>> the CSR to our PKI vendor.  At the same time, it's not clear to me
>> through searching documents how I would extend the CA chain.  Do I
>> need to submit that CSR or is there a way for me to do this on my
>> own?
>> 
>Welcome to FreeIPA :)
>
>If you have a relationship with a Certificate Authority willing to
>sign an intermediate CA certificate for you, then you can use the
>--external-ca option, submit the generate CSR to your CA and once
>you receive your signed CA certificate, continue ipa-server-install.
>
>For a publicly-trusted intermediate CA cert, you are probably
>looking at $10,000s or $100,000s in fees, infrastructure and
>compliance costs to achieve this.  Public CAs much prefer to keep
>you coming back to them for publicly trusted certificates :)
>
>If you already have some internal CA for your organisation, you can
>use it to sign the CSR.
>
>Otherwise, you can install FreeIPA with its own root CA (this is the
>default).
>
>HTH,
>Fraser
>
>> Any assistance is much appreciated.
>> 
>> Sean
>> 
>
>> -- 
>> 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] Duplicate objects after 4.1 ipa-server upgrade

[Ludwig Krispenz]

On 11/03/2015 04:24 PM, Andrew Krause wrote:

I upgraded 4 at the same time actually.  It makes sense why the objects were 
created and I do understand how replication conflicts are handled.  I just 
wanted to be absolutely certain that it was ok to delete these objects since it 
seems pointless to ever keep them around.  Has there been any talk of a 
mechanism to just handle this on a regular basis (not that this situation 
should happen regularly)?
there are requests to hide these conflict entries so that the do not 
interfere with other operations and there is ongoing discussion  in DS 
to implement another mechanism which doesn't have these side effects.
But on the other hand these entries are not generated out of the blue, 
they indicate a scenario on the application/client side where the same 
entry is added simultaneously on two or more servers. maybe as Martin 
said by upgrading in parallel or by impatient clients which move to 
another servers if no immediat success or by misconfigured proxies or 
load balancers which send ops to multiple masters. So these  conflict 
entries could also seen as a hint that somthing is or was wrong.
You can proactively check for these entries before and harm is done and 
delete them. Do

ldapsearch -b "" "nsds5ReplConflict=*" nsds5ReplConflict




On Nov 3, 2015, at 1:42 AM, Martin Kosek  wrote:

On 11/03/2015 12:05 AM, Andrew Krause wrote:

After upgrading to 4.1 I have duplicated permission objects in my directory 
with names including nsuniqueid.  Is it safe to delete all of these objects?  
Somehow this is only causing an issue for a specific user hitting a specific 
HBAC policy.

(Mon Nov  2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_eval_user_element] 
(0x0080): Parse error on [cn=Read PassSync Managers 
Configuration+nsuniqueid=4ae3220f-4d2b11e5-a06ffcc2-215714a9 ..
(Mon Nov  2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_ctx_to_rules] 
(0x0020): Could not construct eval request
(Mon Nov  2 14:29:23 2015) [sssd[be[blue-shift.com]]] [ipa_hbac_evaluate_rules] 
(0x0020): Could not construct HBAC rules


This is causing authentication to fail for the user in question, and I would 
like to get rid of these useless objects if they are no longer necessary.

It looks like you had some replication problem in your network, or maybe
upgraded 2 FreeIPA instances at the same time, so they both generated
conflicting permissions?

In any case, it should be case to delete the permissions with nsuniqueid,
FreeIPA should generate the managed permissions from scratch anyway, if they
are missing and upgrade is run again.

More info on replication conflicts here:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#Solving_Common_Replication_Conflicts-Solving_Naming_Conflicts

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] Duplicate objects after 4.1 ipa-server upgrade

[Andrew Krause]

I upgraded 4 at the same time actually.  It makes sense why the objects were 
created and I do understand how replication conflicts are handled.  I just 
wanted to be absolutely certain that it was ok to delete these objects since it 
seems pointless to ever keep them around.  Has there been any talk of a 
mechanism to just handle this on a regular basis (not that this situation 
should happen regularly)?


> On Nov 3, 2015, at 1:42 AM, Martin Kosek  wrote:
> 
> On 11/03/2015 12:05 AM, Andrew Krause wrote:
>> After upgrading to 4.1 I have duplicated permission objects in my directory 
>> with names including nsuniqueid.  Is it safe to delete all of these objects? 
>>  Somehow this is only causing an issue for a specific user hitting a 
>> specific HBAC policy. 
>> 
>> (Mon Nov  2 14:29:23 2015) [sssd[be[blue-shift.com]]] 
>> [hbac_eval_user_element] (0x0080): Parse error on [cn=Read PassSync Managers 
>> Configuration+nsuniqueid=4ae3220f-4d2b11e5-a06ffcc2-215714a9 ..
>> (Mon Nov  2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_ctx_to_rules] 
>> (0x0020): Could not construct eval request
>> (Mon Nov  2 14:29:23 2015) [sssd[be[blue-shift.com]]] 
>> [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules
>> 
>> 
>> This is causing authentication to fail for the user in question, and I would 
>> like to get rid of these useless objects if they are no longer necessary.  
> 
> It looks like you had some replication problem in your network, or maybe
> upgraded 2 FreeIPA instances at the same time, so they both generated
> conflicting permissions?
> 
> In any case, it should be case to delete the permissions with nsuniqueid,
> FreeIPA should generate the managed permissions from scratch anyway, if they
> are missing and upgrade is run again.
> 
> More info on replication conflicts here:
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#Solving_Common_Replication_Conflicts-Solving_Naming_Conflicts
> 
> 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] IPA Replication not working for User and DNS

[Yogesh Sharma]

LDAPS is also fine:

[root@ipa-inf-prd-ng2-02 ~]# ldapsearch -x -H ldaps://
ipa-inf-prd-ng2-01.klikpay.int -s base -b '' namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#

#
dn:
namingContexts: cn=changelog
namingContexts: dc=klikpay,dc=int
namingContexts: o=ipaca

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@ipa-inf-prd-ng2-02 ~]#


*Best Regards,*

*__*

*Yogesh Sharma*
*Email: yks0...@gmail.com  | Web: www.initd.in
 *

*RHCE, VCE-CIA, RACKSPACE CLOUD U Certified*

   



On Mon, Nov 2, 2015 at 6:00 PM, Martin Basti  wrote:

>
>
> On 02.11.2015 08:01, Yogesh Sharma wrote:
>
> Listening:
>
> [root@ipa-inf-prd-ng2-02 ~]# telnet ipa-inf-prd-ng2-01.klikpay.int 636
> Trying 172.16.32.10...
> Connected to ipa-inf-prd-ng2-01.klikpay.int.
> Escape character is '^]'.
>
>
> Can you try also ldaps with ldapsearch?
>
>
> *Best Regards,*
>
> *__ *
>
> *Yogesh Sharma *
> *Email:  yks0...@gmail.com  | Web:
> www.initd.in  *
>
> *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified*
>
>    
> 
> 
>
> On Mon, Nov 2, 2015 at 12:23 PM, Alexander Bokovoy < 
> aboko...@redhat.com> wrote:
>
>> On Mon, 02 Nov 2015, Yogesh Sharma wrote:
>>
>>> Adding to this, I am able to do ldsearch from the server which I am
>>> trying
>>> to make replica.
>>>
>>> [root@ipa-inf-prd-ng2-02 ~]# ldapsearch -x -H ldap://
>>> ipa-inf-prd-ng2-01.klikpay.int -s base -b '' namingContexts
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base <> with scope baseObject
>>> # filter: (objectclass=*)
>>> # requesting: namingContexts
>>> #
>>>
>> What about port 636? Replica install requires LDAPS.
>>
>> --
>> / 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

Re: [Freeipa-users] FreeIPA and Samba4

[Sumit Bose]

On Tue, Nov 03, 2015 at 01:09:53PM +0100, Troels Hansen wrote:
> Hi again, so I finally got time to look further into this.
> 
> This task works:
> 
> dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config
> add:objectclass:top,extensibleObject
> add:cn:$TIME-$FQDN-$LIBARCH
> add:nsslapd-basedn:"$SUFFIX"
> add:delay:0
> add:ttl:3600
> 
> However, the task gets generated, but no output can be pulled from the task:
> 
> ldapsearch -D "cn=Directory Manager" -W -b 
> 'cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config'
> Enter LDAP Password: 
> # extended LDIF
> #
> # LDAPv3
> # base 
>  
> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
> 
> # 1446551851-kenai.casalogic.lan-64, ipa-sidgen-task, tasks, config
> dn: cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config
> objectClass: top
> objectClass: extensibleObject
> nsslapd-basedn: dc=casalogic,dc=lan
> delay: 0
> cn: 1446551851-kenai.casalogic.lan-64
> ttl: 3600
> nstaskcurrentitem: 1
> nstasktotalitems: 1
> nstaskexitcode: 32
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 2
> # numEntries: 
> 
> Only a exitcode 32
> The nstaskcurrentitem and nstasktotalitems remains the same till the task 
> disappeares.
> Any way do debug these taske further to find out which user it stops at, as 
> it looks like it detects an error at one user and stops the task?

You can activate 'Plug-in debugging' by setting the
nsslapd-errorlog-level attribute of cn=config to 65536, see
http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting for
details. Make sure to switch it back to 0 after running the sidgen task
because the logging is quite expensive.

HTH

bye,
Sumit

> 
> - On Oct 30, 2015, at 3:19 PM, Alexander Bokovoy aboko...@redhat.com 
> wrote:
> 
> > On Fri, 30 Oct 2015, Troels Hansen wrote:
> >>
> >>
> >>
> >>> I think it should be
> >>> add:nsslapd-basedn: cn=accounts,$SUFFIX
> >>> not
> >>> add:basedn:"cn=accounts,$SUFFIX"
> >>>
> >>> this is what sidgen task expects and it returns constraint violation
> >>> error if parameters are wrong:
> >>>
> >>>str = fetch_attr(e, "nsslapd-basedn", NULL);
> >>>if (str == NULL) {
> >>>LOG_FATAL("Missing nsslapd-basedn!\n");
> >>>*returncode = LDAP_CONSTRAINT_VIOLATION;
> >>>ret = SLAPI_DSE_CALLBACK_ERROR;
> >>>goto done;
> >>>}
> >>>
> >>
> >>I think you are right.
> >>Don't know what I have tested, but it brings me a different error, that I 
> >>didn't
> >>see before:
> >>
> >>ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR:
> >>{'desc': 'Operations error'}
> >>ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations
> >>error:
> >>ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The
> >>ipa-ldap-updater command was successful
> >>
> >>Where did you find the source for the sidgen task? I could try  looking at 
> >>at it
> >>myself, but can't find it.
> > You can check it here:
> > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221
> > 
> > --
> > / Alexander Bokovoy
> 
> -- 
> Med venlig hilsen 
> 
> Troels Hansen 
> 
> Systemkonsulent 
> 
> Casalogic A/S 
> 
> 
> T (+45) 70 20 10 63 
> 
> M (+45) 22 43 71 57 
> 
> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
> meget mere.
> 
> -- 
> 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] FreeIPA and Samba4

[Troels Hansen]

Hi again, so I finally got time to look further into this.

This task works:

dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config
add:objectclass:top,extensibleObject
add:cn:$TIME-$FQDN-$LIBARCH
add:nsslapd-basedn:"$SUFFIX"
add:delay:0
add:ttl:3600

However, the task gets generated, but no output can be pulled from the task:

ldapsearch -D "cn=Directory Manager" -W -b 
'cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config'
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base 
 
with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# 1446551851-kenai.casalogic.lan-64, ipa-sidgen-task, tasks, config
dn: cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config
objectClass: top
objectClass: extensibleObject
nsslapd-basedn: dc=casalogic,dc=lan
delay: 0
cn: 1446551851-kenai.casalogic.lan-64
ttl: 3600
nstaskcurrentitem: 1
nstasktotalitems: 1
nstaskexitcode: 32

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 

Only a exitcode 32
The nstaskcurrentitem and nstasktotalitems remains the same till the task 
disappeares.
Any way do debug these taske further to find out which user it stops at, as it 
looks like it detects an error at one user and stops the task?

- On Oct 30, 2015, at 3:19 PM, Alexander Bokovoy aboko...@redhat.com wrote:

> On Fri, 30 Oct 2015, Troels Hansen wrote:
>>
>>
>>
>>> I think it should be
>>> add:nsslapd-basedn: cn=accounts,$SUFFIX
>>> not
>>> add:basedn:"cn=accounts,$SUFFIX"
>>>
>>> this is what sidgen task expects and it returns constraint violation
>>> error if parameters are wrong:
>>>
>>>str = fetch_attr(e, "nsslapd-basedn", NULL);
>>>if (str == NULL) {
>>>LOG_FATAL("Missing nsslapd-basedn!\n");
>>>*returncode = LDAP_CONSTRAINT_VIOLATION;
>>>ret = SLAPI_DSE_CALLBACK_ERROR;
>>>goto done;
>>>}
>>>
>>
>>I think you are right.
>>Don't know what I have tested, but it brings me a different error, that I 
>>didn't
>>see before:
>>
>>ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR:
>>{'desc': 'Operations error'}
>>ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations
>>error:
>>ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The
>>ipa-ldap-updater command was successful
>>
>>Where did you find the source for the sidgen task? I could try  looking at at 
>>it
>>myself, but can't find it.
> You can check it here:
> https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221
> 
> --
> / Alexander Bokovoy

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere.

-- 
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] [Freeipa-devel] Open ports for client can auth over wan

[Petr Spacek]

Hello,

please do not drop freeipa-users list when replying. There is plenty of smart
people who can reply instead of me :-) Anyway:

On 3.11.2015 10:31, Martin Jørgensen wrote:
> Okay all of them, also bind is that not a vulnerability?

If you are asking about DNS server BIND, then you need to do hardening steps
as usual for publicly-available DNS server. There are other things to
consider, please read following thread:
https://www.redhat.com/archives/freeipa-users/2014-April/msg00243.html

Let us know if you have further questions.

Petr^2 Spacek

> 2015-11-03 9:55 GMT+01:00 Petr Spacek :
> 
>> On 3.11.2015 09:42, Martin Jørgensen wrote:
>>> Hi
>>>
>>> Loves freeipa, using it on all of my machines, i have som vm in the
>> cloud,
>>> which port do i have to open out for these client can auth?
>>
>> ipa-server-install prints list of ports you need to open. For full
>> functionality you need to open all of them.
>>
>> --
>> Petr^2 Spacek

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