date:20170210

Re: [Freeipa-users] Jenkins integration?

2017-02-10 Thread Harald Dunkel

On 02/10/17 15:07, Tomasz Torcz wrote:
> On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote:
>> Hi folks,
>>
>> did anybody succeed in using Freeipa for Jenkins' LDAP module?
>> I can't make it work :-(.
> 
>   I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP.
> I have Jenkins set to PAM authentication, which in turn goes thru SSSD.
> It works fine, groups are resolved correctly, too.
> 

Thats plan B. Its good to know that this works, but I
don't give up that easy.

My major problem ist that jenkins doesn't write propper
log files. Java is as awkward as it was 20 years ago.


Thanx
Harri

-- 
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] bind-dyndb-ldap, AXFR and DS records

2017-02-10 Thread Ben Roberts

Hi Tomas,

> If I understand you correctly, the primary server is filled with data
> using bind-dyndb-ldap from an LDAP backend. Then the DS records are
> present on the primary server. At this point, bind-dyndb-ldap's work
> should be done, since it only serves as the backend LDAP driver for BIND.

You understand correctly.

> The issue happens when you try to replicate the zone to the secondary
> nameserver using AXFR. This leads me to believe that this might be some
> issue in the BIND component itself. Perhaps some special configuration
> is required.

I've not found any documentation that suggests special configuration
is required. I spoke to some of the people in #bind before posting to
this list, they were also surprised it wasn't working.

> It might help you if you'd test the setup without bind-dyndb-ldap with
> some mock data directly in BIND. If the AXFR doesn't contain the DS
> records then, it's related to BIND. Perhaps the BIND users
> (bind-us...@lists.isc.org) list might be able to assist you.

I've setup the test case directly on one of the primary nameservers
with a couple of domains and do see the DS glue records included in
the AXFR, so the missing records seem to only be happening when the
zonefile is backed by bind-dyndb-ldap.

Regards,
Ben Roberts

-- 
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] [SOLVED] CA not found?

2017-02-10 Thread Guillermo Fuentes

Hi Fraser,

Although I modified the ids to release the data, I made sure to use
consistent ids where they appeared.
 As you noted, there was a discrepancy and changing the 'ipacaid'
attribute of cn=ipa,cn=cas,cn=ca,dc=ipa,dc=local to match the
authorityID from Dogtag fixed the issue. We're now able to sign
certificates as before. Yay!!!
As of what could have cause this discrepancy, the only thing I can
think of is that, back when we migrated the cluster, there were a few
times where the cloning of the CA from 3.x to 4.x failed.

Thank you very much for your help with this! I really appreciate it!
Have a great time off!
Guillermo

On Fri, Feb 10, 2017 at 5:03 AM, Fraser Tweedale  wrote:
> On Thu, Feb 09, 2017 at 09:01:01PM -0500, Guillermo Fuentes wrote:
>> As we're enforcing encryption, here is via ldaps:
>> $ ldapsearch -H ldaps://`hostname` -D "cn=Directory Manager"  -W -s
>> sub -b ou=authorities,ou=ca,o=ipaca   Enter LDAP
>> Password:
>> # extended LDIF
>> #
>> # LDAPv3
>> # base

Re: [Freeipa-users] Jenkins integration?

2017-02-10 Thread Tomasz Torcz

On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote:
> Hi folks,
> 
> did anybody succeed in using Freeipa for Jenkins' LDAP module?
> I can't make it work :-(.

  I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP.
I have Jenkins set to PAM authentication, which in turn goes thru SSSD.
It works fine, groups are resolved correctly, too.

-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev

-- 
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] Jenkins integration?

2017-02-10 Thread Harald Dunkel

Hi folks,

did anybody succeed in using Freeipa for Jenkins' LDAP module?
I can't make it work :-(.

On the command line the jenkins user appears to have read access
to the LDAP database. The config UI for Jenkin's LDAP plugin
doesn't complain, either. Jenkins System Log appears to be fine.
But if a "freeipa user" tries to login in Jenkins, then he gets
an "invalid login information".

For Confluence (both are Java Webapps) there was no such problem.

Every helpful hint is highly appreciated.
Harri

-- 
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 - Insufficient 'add' privilege ?

2017-02-10 Thread Martin Babinsky


On 02/10/2017 01:29 PM, lejeczek wrote:

hi everyone,

I'm trying something mundane(can't think why, how my setup would be
special/different) - replica installation - but I hit this:

 [42/44]: activating extdom plugin
  [43/44]: tuning directory server
  [44/44]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERRORInsufficient
access: Insufficient 'add' privilege to add the entry
'cn=NTP,cn=work3.whale.private,cn=masters,cn=ipa,cn=etc,dc=whale,dc=private'.
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
ipa-replica-install command failed. See /var/log/ipareplica-install.log
for more information

$and logs tail:

2017-02-10T12:20:46Z DEBUG retrieving schema for SchemaCache
url=ldapi://%2fvar%2frun%2fslapd-WHALE-PRIVATE.socket
conn=
2017-02-10T12:20:47Z DEBUG Destroyed connection context.ldap2_84192272
2017-02-10T12:20:47Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute
return_value = self.run()
  File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line
318, in run
cfgr.run()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 310, in run
self.execute()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 332, in execute
for nothing in self._executor():
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 372, in __runner
self._handle_exception(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 394, in _handle_exception
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 362, in __runner
step()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 359, in 
step = lambda: next(self.__gen)
  File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
line 81, in run_generator_with_yield_from
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
line 59, in run_generator_with_yield_from
value = gen.send(prev_value)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 586, in _configure
next(executor)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 372, in __runner
self._handle_exception(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 449, in _handle_exception
self.__parent._handle_exception(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 394, in _handle_exception
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 446, in _handle_exception
super(ComponentBase, self)._handle_exception(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 394, in _handle_exception
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 362, in __runner
step()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 359, in 
step = lambda: next(self.__gen)
  File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
line 81, in run_generator_with_yield_from
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
line 59, in run_generator_with_yield_from
value = gen.send(prev_value)
  File "/usr/lib/python2.7/site-packages/ipapython/install/common.py",
line 63, in _install
for nothing in self._installer(self.parent):
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
line 1714, in main
promote(self)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
line 364, in decorated
func(installer)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
line 1425, in promote
remote_api.env.realm)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py",
line 43, in ntp_ldap_enable
ntp.ldap_enable('NTP', fqdn, None, base_dn)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 512, in ldap_enable
self.admin_conn.add_entry(entry)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line
1492, in add_entry
self.conn.add_s(str(entry.dn), list(attrs.items()))
  File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__
self.gen.throw(type, value, traceback)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line
971, in error_handler
raise errors.ACIError(info=info)

2017-02-10T12:20:47Z DEBUG The ipa-replica-install command failed,
exception: ACIError: Insufficient access: Insufficient 'add' privilege
to add the entry
'cn=NTP,cn=work3.whale.private,cn=masters,cn=ipa,cn=etc,dc=whale,dc=private'.
2017-02-10T12:20:47Z

[Freeipa-users] replica install - Insufficient 'add' privilege ?

2017-02-10 Thread lejeczek


hi everyone,

I'm trying something mundane(can't think why, how my setup 
would be special/different) - replica installation - but I 
hit this:


 [42/44]: activating extdom plugin
  [43/44]: tuning directory server
  [44/44]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROR 
Insufficient access: Insufficient 'add' privilege to add the 
entry 
'cn=NTP,cn=work3.whale.private,cn=masters,cn=ipa,cn=etc,dc=whale,dc=private'.
ipa.ipapython.install.cli.install_tool(Replica): ERROR
The ipa-replica-install command failed. See 
/var/log/ipareplica-install.log for more information


$and logs tail:

2017-02-10T12:20:46Z DEBUG retrieving schema for SchemaCache 
url=ldapi://%2fvar%2frun%2fslapd-WHALE-PRIVATE.socket 
conn=
2017-02-10T12:20:47Z DEBUG Destroyed connection 
context.ldap2_84192272
2017-02-10T12:20:47Z DEBUG   File 
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", 
line 171, in execute

return_value = self.run()
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/cli.py", 
line 318, in run

cfgr.run()
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 310, in run

self.execute()
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 332, in execute

for nothing in self._executor():
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 372, in __runner

self._handle_exception(exc_info)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 362, in __runner

step()
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 359, in 

step = lambda: next(self.__gen)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/util.py", 
line 81, in run_generator_with_yield_from

six.reraise(*exc_info)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/util.py", 
line 59, in run_generator_with_yield_from

value = gen.send(prev_value)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 586, in _configure

next(executor)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 372, in __runner

self._handle_exception(exc_info)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 449, in _handle_exception

self.__parent._handle_exception(exc_info)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 446, in _handle_exception

super(ComponentBase, self)._handle_exception(exc_info)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 362, in __runner

step()
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/core.py", 
line 359, in 

step = lambda: next(self.__gen)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/util.py", 
line 81, in run_generator_with_yield_from

six.reraise(*exc_info)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/util.py", 
line 59, in run_generator_with_yield_from

value = gen.send(prev_value)
  File 
"/usr/lib/python2.7/site-packages/ipapython/install/common.py", 
line 63, in _install

for nothing in self._installer(self.parent):
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", 
line 1714, in main

promote(self)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", 
line 364, in decorated

func(installer)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", 
line 1425, in promote

remote_api.env.realm)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", 
line 43, in ntp_ldap_enable

ntp.ldap_enable('NTP', fqdn, None, base_dn)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", 
line 512, in ldap_enable

self.admin_conn.add_entry(entry)
  File 
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", 
line 1492, in add_entry

self.conn.add_s(str(entry.dn), list(attrs.items()))
  File "/usr/lib64/python2.7/contextlib.py", line 35, in 
__exit__

self.gen.throw(type, value, traceback)
  File 
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", 
line 971, in error_handler

raise errors.ACIError(info=info)

2017-02-10T12:20:47Z DEBUG The ipa-replica-install command 
failed, exception: ACIError: Insufficient access: 
Insufficient 'add' privilege to add the entry

Re: [Freeipa-users] CA not found?

2017-02-10 Thread Fraser Tweedale

On Thu, Feb 09, 2017 at 09:01:01PM -0500, Guillermo Fuentes wrote:
> As we're enforcing encryption, here is via ldaps:
> $ ldapsearch -H ldaps://`hostname` -D "cn=Directory Manager"  -W -s
> sub -b ou=authorities,ou=ca,o=ipaca   Enter LDAP
> Password:
> # extended LDIF
> #
> # LDAPv3
> # base

Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

2017-02-10 Thread Tomas Krizek

On 02/10/2017 08:42 AM, Ben Roberts wrote:
> Hi Martin,
>
>> I'm not sure how your DNS data are structured, but usually (properly)
>> DS record is located in parent zone, so AXFR for
>> subdomain.exmale.com should not return DS record, but AXFR
>> for example.com should return DS record of
>> subdomain.example.com.
> Herein lies the problem. The nameservers are authoritative for both
> the parent and child zones, and both are replicated from the primaries
> to the secondary nameserver. The DS glue records for the child zone
> contained within the parent zone are not being replicated across to
> the secondary via AXFR. Thus there is a complete chain for DNSSEC
> trust when queries are directed at the primaries, but not when queries
> are directed at the secondary nameserver.
>
> This affects both the DS glue records, and also the apex DS records
> which don't need to be present, but which bind-dyndb-ldap makes
> available automatically anyway. I raise this not because it's needed,
> but it might be relevant to identifying where the root cause is.
>
> Regards,
> Ben Roberts
If I understand you correctly, the primary server is filled with data
using bind-dyndb-ldap from an LDAP backend. Then the DS records are
present on the primary server. At this point, bind-dyndb-ldap's work
should be done, since it only serves as the backend LDAP driver for BIND.

The issue happens when you try to replicate the zone to the secondary
nameserver using AXFR. This leads me to believe that this might be some
issue in the BIND component itself. Perhaps some special configuration
is required.

It might help you if you'd test the setup without bind-dyndb-ldap with
some mock data directly in BIND. If the AXFR doesn't contain the DS
records then, it's related to BIND. Perhaps the BIND users
(bind-us...@lists.isc.org) list might be able to assist you.

-- 
Tomas Krizek




signature.asc
Description: OpenPGP digital signature
-- 
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] Looking for instructions on one way subtree sync IPA->IPA

2017-02-10 Thread David Kupka

On Thu, Feb 09, 2017 at 01:45:42PM +, Piper, Nick wrote:
> Hi Alexander,
> 
> Alexander Bokovoy wrote:
> >On to, 09 helmi 2017, Piper, Nick wrote:
> 
> >>We're currently using FreeIPA 4.2.0, and we have two unrelated
> >>instances of IdM server. We'd like the user list which IPA maintains
> >>in one, to be a superset of the other; so we're looking for one way
> >>replication (of cn=users,cn=accounts,dc=realm, not necessarily of host
> >>entries etc.)
> 
> >>We use a different 'dc' in each instance, and could use a different cn
> >>too if needed.
> 
> >In short, there is no support for IPA-IPA trust or replication. There
> >are many reasons for that, including some complex technical issues on
> >how this could be reliably working.
> 
> >If you are after actual POSIX systems where users need to logon to use
> >their services, you may try to configure SSSD with two different domains
> >(for IPA1 and IPA2). You can look at discussion we had in 2014:
> >https://www.redhat.com/archives/freeipa-users/2014-January/msg00075.html
> >You are not necessarily need to enroll the machine in two different
> >realms, any Kerberos principal would do instead of a host principal to
> >authenticate against IPA LDAP (see sssd-ldap man page for details on
> >ldap_sasl_authid).
> 
> Thanks, so the idea here would be for SSSD (and any other software
> which uses krb or LDAP) to be configured to use both our IPA instances
> simultaneously. I'll ponder on this and check into if each of our
> applications has support for multiple LDAP servers.
> 
> >>We believe we need one way sync (including passwords) to be able to
> >>authenticate users which are mastered in the 'remote' IPA, even when
> >>the 'remote' IPA is offline. Another option we might explore is
> >>'cross-forest trust', although I believe this would make
> >>authentication unavailable if the 'master' IPA is unavailable. Both
> >>are discussed at
> >>https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#summary-indirect
> >>, but again in the context of AD/IPA rather than IPA/IPA.
> 
> >>I'd welcome any pointers on trust or one-way replication between two
> >>IPA instances!
> 
> >You are stuck, there is no such support between different IPA
> >deployments.
> 
> >It would help to actually explain your real use case. So far you
> >outlined above your approaches to solve a problem which is not really
> >stated upfront.
> 
> Thanks - I'll try to explain the wider picture:
> 
> We have a Hadoop deployment which uses an instance of FreeIPA both for
> the Operating Systems (using SSSD) and applications which use LDAP
> (for authentication, authorisation and for directory search.) This
> FreeIPA (Project IPA) is intended to be authoritative for user
> accounts which are specific to the project, such as administrators,
> contractors, and so on. The project fits into a wider estate, which
> uses FreeIPA (call this Enterprise IPA) to manage general user
> accounts.
> 
> For auditing and consistency purposes, the general users managed in
> Enterprise IPA should be able to run POSIX processes under their
> username (in this case YARN containers), log into project tools (which
> use LDAP to Project IPA - although this could be changed to
> SAML/Shibboleth which might avoid Project IPA having to validate
> credentials) and so on.
> 
> 
> +--+  
>
> |  |  
>
> | ++   |  
>
> | ||   |  
>
> | | +---+ +-+ ++  +--+ |   |  
>
> | | | IPA   | |Linux OS | |Linux OS|  | App using| |   |  
>
> | | |   | | | ||  | LDAP | |   |  
>
> | | +---+ +-+ ++  +--+ |   |  
>
> | ||   |  
>
> | |^   |   |  
>
> | |Project +  
>
> | ++   |  user1 can own   
>
> |  |  processes here  
>
> |  |  
>
> |  |  
>
> |  |  
>
> |

Re: [Freeipa-users] Jenkins integration?

Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

Re: [Freeipa-users] [SOLVED] CA not found?

Re: [Freeipa-users] Jenkins integration?

[Freeipa-users] Jenkins integration?

Re: [Freeipa-users] replica install - Insufficient 'add' privilege ?

[Freeipa-users] replica install - Insufficient 'add' privilege ?

Re: [Freeipa-users] CA not found?

Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

Re: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA

10 matches

Site Navigation

Mail list logo

Footer information