Re: [Freeipa-users] External (AD) groups and sudo/hbac in IPA 4.2

2016-10-11 Thread Alexander Bokovoy

On ke, 12 loka 2016, Robert Sturrock wrote:

Hi All.

We’re attempting to setup an IPA (4.2) service on RHEL7.2 to provide
better connectivity to our (large) organisational AD service for Linux
clients.

We have setup IPA and configured a suitable AD trust (with SID POSIX
mapping) in the hope that users will be able to access IPA resources
(hosts, storage) using existing AD credentials and groups.  This
working fine - we can login to Linux hosts using AD credentials and see
the AD groups.

However, it would appear that in order to use AD group membership as
the basis for Linux HBAC or sudo, we need to firstly _map_ the AD
groups to an equivalent IPA (POSIX) group?  Is this correct?


In HBAC and SUDO rules you need to make sure two things are in place:
- on the host level the identities which are subject to the rules are
 available in POSIX namespace

- on the LDAP server level the identities which are subject to the rules
 are real LDAP objects in IPA LDAP server. This is how LDAP schema is
 built.

AD users and groups do not exist in IPA LDAP server, thus they need to
be somehow presented there. This is important technical limitation, an
alternative to which is inherent integrity inconsistency. We don't want
to have inconsistent data relationships.

'External' groups are means to solve this, thanks to the nested group
support in IPA LDAP. On the host level SSSD translates these 'external'
group members to POSIX identities and since POSIX group namespace is
flat, this works well.



I can see that it’s possible to define ‘external’ *users* (not groups)
in some cases, but this function appears to be deprecated.

You don't need to map groups only, the mechanism we built allows you to
specify any resolvable (by SSSD on IPA master) SID of an object from
Active Directory. This means that specifying

 ipa group-add-member my_external_group --external 'AD\ShinyUser'

is going to work in the same way as

 ipa group-add-member my_external_group --external 'AD\Shiny Members'

-- as long as SIDs for 'AD\ShinyUser' and 'AD\Shiny Members' objects are
resolvable by SSSD on the IPA master in question, you can add them as
members of the 'my_external_group'. Your 'my_external_group' can have a
mixture of members and SSSD will do a resolution of those when
performing HBAC rules checks. This all works because POSIX namespace has
no nested groups, so any nested group membership that leads
'AD\ShinyUser' to be a member of a POSIX group will result in
'AD\ShinyUser' to be treated as a member of a POSIX group in question.

Where did you find a sign or statement that mapping 'external' users is
a deprecated feature?


We have large numbers of groups in our AD (~50k), so obviously that’s a
lot of mapping!

Do you really need to have all ~50K groups mapped to assign access controls on
the Linux side? While those ~50K on the AD side may make sense for AD
access, we found out that in many cases access patterns on the Linux
side are quite different to the group distribution on AD side so people
end up creating a different group distribution, thus making the use of
'external' groups a feature rather than a limitation.

--
/ 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] External (AD) groups and sudo/hbac in IPA 4.2

2016-10-11 Thread Lachlan Musicman
On 12 October 2016 at 15:23, Robert Sturrock  wrote:

> Hi All.
>
> We’re attempting to setup an IPA (4.2) service on RHEL7.2 to provide
> better connectivity to our (large) organisational AD service for Linux
> clients.
>
> We have setup IPA and configured a suitable AD trust (with SID POSIX
> mapping) in the hope that users will be able to access IPA resources
> (hosts, storage) using existing AD credentials and groups.  This working
> fine - we can login to Linux hosts using AD credentials and see the AD
> groups.
>
> However, it would appear that in order to use AD group membership as the
> basis for Linux HBAC or sudo, we need to firstly _map_ the AD groups to an
> equivalent IPA (POSIX) group?  Is this correct?
>
> I can see that it’s possible to define ‘external’ *users* (not groups) in
> some cases, but this function appears to be deprecated.
>
> We have large numbers of groups in our AD (~50k), so obviously that’s a
> lot of mapping!
>
>

Hi Rob,

It should work with groups no problems. We found a few issues with sssd
<1.14. To get the up to date sssd for the hosts, the best bet is the COPR
repos

https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/

As for groups working with HBAC, it should work no problems. Yes to mapping
though. Here is the process:

1. Create an external group for your AD users/groups
2. Add AD group name to that external group (this AD group's existence will
be confirmed by IPA->AD trust or command will fail)
3. Create POSIX group
4. add group created in step 1 to group created in step 3

And here are some example commands to do that, as we executed them here, in
the same order:

ipa group-add --desc="petermac.org.au external map" ad_users_external
--external
ipa group-add-member ad_external --external 'PMCI\Bioinf-Cluster'
ipa group-add --desc="petermac.org.au AD users" ad_users
ipa group-add-member ad_users --groups ad_users_external

Let me know how you go

L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] External (AD) groups and sudo/hbac in IPA 4.2

2016-10-11 Thread Robert Sturrock
Hi All.

We’re attempting to setup an IPA (4.2) service on RHEL7.2 to provide better 
connectivity to our (large) organisational AD service for Linux clients.

We have setup IPA and configured a suitable AD trust (with SID POSIX mapping) 
in the hope that users will be able to access IPA resources (hosts, storage) 
using existing AD credentials and groups.  This working fine - we can login to 
Linux hosts using AD credentials and see the AD groups.

However, it would appear that in order to use AD group membership as the basis 
for Linux HBAC or sudo, we need to firstly _map_ the AD groups to an equivalent 
IPA (POSIX) group?  Is this correct?

I can see that it’s possible to define ‘external’ *users* (not groups) in some 
cases, but this function appears to be deprecated.

We have large numbers of groups in our AD (~50k), so obviously that’s a lot of 
mapping!

Regards,

Robert.

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

2016-10-11 Thread Loris Santamaria
If you just need to join a handful of windows machines to a freeIPA
domain, try with these instructions:

https://www.redhat.com/archives/freeipa-users/2013-September/msg00226.h
tml

Best regards 

El mar, 11-10-2016 a las 17:43 -0700, Alan Latteri escribió:
> > > > > I am trying to get this to work, but our Samba server is not the same
machine as out IPA server, and these instructions seem to assume
that.  Any ideas?  All I need is the 1 windows machine in our network
to be able to access our linux based server, using the same user/pass
as that of our IPA authenticated linux machines.
> 
> > > > On Oct 10, 2016, at 1:35 PM, Степаненко Алексей  wrote:
> > 
> >   
> > 
> >   
> >   I read again the topic
> > > >   http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Se
rver_With_IPA/NTMLSSP
> > 
> > > >   It works exactly as I wanted ipa-adtrust-install created next
configuration:
> > 
> > 
> >   
> > 
> > $ net conf list
> > 
> > [global]
> > 
> >     workgroup = WORKGROUP
> > 
> >     netbios name = SMB
> > 
> >     realm = GW.SPB.RU
> > 
> >     kerberos method = dedicated keytab
> > 
> >     dedicated keytab file = FILE:/etc/samba/samba.keytab
> > 
> >     create krb5 conf = no
> > 
> >     security = user
> > 
> >     domain master = yes
> > 
> >     domain logons = yes
> > 
> >     log level = 1
> > 
> >     max log size = 10
> > 
> >     log file = /var/log/samba/log.%m
> > 
> >     passdb backend =
> > ipasam:ldapi://%2fvar%2frun%2fslapd-GW-SPB-RU.socket
> > 
> >     disable spoolss = yes
> > 
> >     ldapsam:trusted = yes
> > 
> >     ldap ssl = off
> > 
> >     ldap suffix = dc=gw,dc=spb,dc=ru
> > 
> >     ldap user suffix = cn=users,cn=accounts
> > 
> >     ldap group suffix = cn=groups,cn=accounts
> > 
> >     ldap machine suffix = cn=computers,cn=accounts
> > 
> >     rpc_server:epmapper = external
> > 
> >     rpc_server:lsarpc = external
> > 
> >     rpc_server:lsass = external
> > 
> >     rpc_server:lsasd = external
> > 
> >     rpc_server:samr = external
> > 
> >     rpc_server:netlogon = external
> > 
> >     rpc_server:tcpip = yes
> > 
> >     rpc_daemon:epmd = fork
> > 
> >     rpc_daemon:lsasd = fork
> > 
> > 
> > 
> > But I don't understand why it wasn't put to smb.conf directly.
> > 
> > 
> > 
> > The second problem is 'passdb backend'. I didn't find any
> > > > documentation about this module. An attempt to replace a file
socket
> > > > on net connection was failed. And I had to make LDAP
replication. It
> > was easy, but "
> > 
> > ipa-replica-prepare" installed whole IPA server (tomcat, java,
> > ldap), not only ldap-server. I need to continue to read
> > documentation. However the problem was solved. 
> > 
> > 
> > 
> > 06.10.2016 23:51, Степаненко Алексей
> >   пишет:
> > 
> > 
> > 
> > > Thank you for your reply. 
> > >   
> > > 
> > > > > >   I've got Samba server for a company, accounts are created
by hand.
> > >   Clients are different windows or linux desktops. 
> > > 
> > >   
> > > 
> > > > > >   I want to install FreeIPA and have one area for managing
accounts
> > > > > >   (SMB, SSH-access for others servers). Now, I prepare clean
samba
> > > > > >   installation for testing. It would be great to use FreeIPA
as
> > >   authorization server for samba. 
> > > 
> > >   
> > > 
> > > > > >   I was looking for information about samba + freeIPA, but I
found
> > >   only this document. Maybe, I miss obvious things. 
> > > 
> > >   
> > > 
> > >   
> > > 
> > >   06.10.2016 20:31, Loris Santamaria пишет: 
> > > 
> > > > The document you are linking to explains
> > > > how to configure a samba file 
> > > > 
> > > > > > > > server in a freeipa domain, which is one of many ways
you can
> > > > configure 
> > > > 
> > > > and use a samba server. 
> > > > 
> > > > 
> > > > 
> > > > > > > > What do you want to achieve with samba, and what is
your current
> > > > setup? 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > > > > El jue, 06-10-2016 a las 19:23 +0300, Степаненко
Алексей
> > > > escribió: 
> > > > 
> > > > > Hello. 
> > > > >   
> > > > > 
> > > > >   I've read the topic about FreeIPA and SAMBA 
> > > > > 
> > > > > > > > > >   
> > > > > > > > > > http://www.freeipa.org/page/Howto/Integrating_a_Sam
ba_File_Server_Wit
> > > > >   
> > > > > 
> > > > >   h_IPA 
> > > > > 
> > > > >   
> > > > > 
> > > > > > > > > >   If I understand clearly, samba's client must be
present in 
> > > > > 
> > > > >   FreeIPA  

Re: [Freeipa-users] IPA Client Install problems

2016-10-11 Thread Tyrell Jentink
Thank you, Rob.

For reference, my full log can be found here: http://pastebin.com/6VLaQjYw

But I would postulate that the interesting bit is this:

> 2016-10-11T22:10:15Z DEBUG stdout=Outgoing update query:
>
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
>
> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
>
> ;; UPDATE SECTION:
>
> trainmaster.ipa.rxrhouse.net. 0 ANY A
>
>
>> Outgoing update query:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  23971
>
> ;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; QUESTION SECTION:
>
> ;350449427.sig-ipa-pdc.ipa.rxrhouse.net.ANY TKEY
>
>
>> ;; ADDITIONAL SECTION:
>
> 350449427.sig-ipa-pdc.ipa.rxrhouse.net. 0 ANY TKEY gss-tsig. 1476223815
>> 1476223815 3 NOERROR 683 
>> YIICpwYJKoZIhvcSAQICAQBuggKWMIICkqADAgEFoQMCAQ6iBwMFACAA
>> AACjggGIYYIBhDCCAYCgAwIBBaESGxBJUEEuUlhSSE9VU0UuTkVUoiow
>> KKADAgEBoSEwHxsDRE5TGxhpcGEtcGRjLmlwYS5yeHJob3VzZS5uZXSj
>> ggE3MIIBM6ADAgESoQMCAQKiggElBIIBIeFubKS/x0aKfc7u/f9Z5Ro8
>> pZZ4RkIlwOWAAuiSxJNmoaIhYgYNitn2pkAII+eKtdialtAI/1418exm
>> sM7zahCj0MWpBIYQZB4tsN9JZMaKF7SK5TlewH9mZitjd+hbQ5iwjklV
>> 8P6OOMsIRIytywnd8eD/988GQz3C5CfBU1pQM5Bkox4vSRawZJRUy0xx
>> C8H4nOOPsJZd9AozsaAZSR4EeA05IbW+gxxIeXjShPDwRF6fs4sNxZUt
>> FEkdujVZOaM4M4olLadzScsXDi2pO/8WqjJdDwMfLD95+CHSiFMSyJqy
>> nwem6dzJTJvyLTq4fKO+ajmUHw5tV30Pg7w9krEiFSTuFkCmKW1a2GQo
>> 5Lm3VQF34cnYTA+5K8yEwLiTqX+kgfAwge2gAwIBEqKB5QSB4u9m77de
>> VD1pQ+DUyBKaC2jOgD/uUWAyfNNojNAtKAMGbHzDWSRASe1Xd+RNgwIa
>> QdT2PC6kHbJMz9jaJu/0fxC9JmPp6Qe6p8CGaQ6IvPGm4838TlGdGhuS
>> YpUwVAEqvl85S23+yT3Qo/O8Qffhi4i/WDdiBHGGDrKF4CCZXJrr/F+L Pd8oabRE81h+
>> 4Tu7KBTApBwWYFYQSct7Q9ZrFiUuQzbpc2ZjXaVLi3ai 
>> uvH2NLWvLwxt8Z8PYRHgTrEYb/QfEluP2qfbo6XuO4UHoF7rN8d28bnw
>> bhUsEYaVs1r8Pxk= 0
>
>
>>
>> 2016-10-11T22:10:15Z DEBUG stderr=Reply from SOA query:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  18681
>
> ;; flags: qr rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; QUESTION SECTION:
>
> ;trainmaster.ipa.rxrhouse.net.  IN  SOA
>
>
>> ;; AUTHORITY SECTION:
>
> ipa.rxrhouse.net.   60  IN  SOA ipa-pdc.ipa.rxrhouse.net.
>> hostmaster.ipa.rxrhouse.net. 1476221978 3600 900 1209600 3600
>
>
>> ;; ADDITIONAL SECTION:
>
> ipa-pdc.ipa.rxrhouse.net. 353   IN  A   10.42.0.11
>
>
>> Found zone name: ipa.rxrhouse.net
>
> The master is: ipa-pdc.ipa.rxrhouse.net
>
> start_gssrequest
>
> Found realm from ticket: IPA.RXRHOUSE.NET 
>
> send_gssrequest
>
> recvmsg reply from GSS-TSIG query
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  23971
>
> ;; flags: qr; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
>
> ;350449427.sig-ipa-pdc.ipa.rxrhouse.net.ANY TKEY
>
>
>> ;; ANSWER SECTION:
>
> 350449427.sig-ipa-pdc.ipa.rxrhouse.net. 0 ANY TKEY gss-tsig. 1466641678
>> 1466728078 3 NOERROR 101 
>> YGMGCSqGSIb3EgECAgMAflQwUqADAgEFoQMCAR6kERgPMjAxNjA2MjMw
>> MDI3NThapQUCAwVDn6YDAgEpqREbD0FELlJYUkhPVVNFLk5FVKoUMBKg
>> AwIBAaELMAkbB2FkLXBkYyQ= 0
>
>
>> dns_tkey_negotiategss: failure GSSAPI error: Major = Unspecified GSS
>> failure.  Minor code may provide more information, Minor = Message stream
>> modified.
>
>
>> 2016-10-11T22:10:15Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g
>> /etc/ipa/.dns_update.txt' returned non-zero exit status 1
>
> 2016-10-11T22:10:15Z ERROR Failed to update DNS records.
>
>
>
This isn't the first time I've seen this "Unspecified GSS failure [...]
Message stream modified" error, and I suspect it to be the root of my
problem... But my google-foo is not strong with this one...  I'm not sure
how to proceed.

On Tue, Oct 11, 2016 at 3:52 PM, Rob Crittenden  wrote:

> Tyrell Jentink wrote:
>
>> First off...  new to the list, thank you in advance for your assistance!
>>
>> My server is Fedora 24 Server, running in a VirtualBox virtual machine.
>> I have FreeIPA Server 4.3.2-2.fc24, installed from the standard
>> repositories, and dnf says it's up to date. FreeIPA has a trust set up
>> with an Windows Server 2012r2 ActiveDirectory server, and it APPEARS to
>> be working...
>>
>> The first client I connected was a Raspberry Pi running Pidora.  This
>> client appears to have connected fine, and appears to be working (I
>> guess I haven't tried logging in as an ActiveDirectory user;  But it's
>> certainly NOT having any DNS issues, as other clients are; See below...)
>>
>> Then I tried connecting a second client, a system running Fedora 24 with
>> FreeIPA Client 4.3.2-2.fc24, and the install went ALMOST according to
>> plan...  Here's the output of ipa-client-install:
>>
>> Discovery was successful!
>> Client hostname: trainmaster.ipa.rxrhouse.net
>> 
>> Realm: IPA.RXRHOUSE.NET 
>> DNS Domain: ipa.rxrhouse.net 
>> IPA Server: ipa-pdc.ipa.rxrhouse.net > >
>> BaseDN: 

Re: [Freeipa-users] FreeIPA and Samba

2016-10-11 Thread Alan Latteri
I am trying to get this to work, but our Samba server is not the same machine 
as out IPA server, and these instructions seem to assume that.  Any ideas?  All 
I need is the 1 windows machine in our network to be able to access our linux 
based server, using the same user/pass as that of our IPA authenticated linux 
machines.


> On Oct 10, 2016, at 1:35 PM, Степаненко Алексей  
> wrote:
> 
> I read again the topic 
> http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA/NTMLSSP
>  
> 
> It works exactly as I wanted
> 
>  ipa-adtrust-install created next configuration:
> $ net conf list
> [global]
> workgroup = WORKGROUP
> netbios name = SMB
> realm = GW.SPB.RU
> kerberos method = dedicated keytab
> dedicated keytab file = FILE:/etc/samba/samba.keytab 
> 
> create krb5 conf = no
> security = user
> domain master = yes
> domain logons = yes
> log level = 1
> max log size = 10
> log file = /var/log/samba/log.%m
> passdb backend = ipasam:ldapi://%2fvar%2frun%2fslapd-GW-SPB-RU.socket
> disable spoolss = yes
> ldapsam:trusted = yes
> ldap ssl = off
> ldap suffix = dc=gw,dc=spb,dc=ru
> ldap user suffix = cn=users,cn=accounts
> ldap group suffix = cn=groups,cn=accounts
> ldap machine suffix = cn=computers,cn=accounts
> rpc_server:epmapper = external
> rpc_server:lsarpc = external
> rpc_server:lsass = external
> rpc_server:lsasd = external
> rpc_server:samr = external
> rpc_server:netlogon = external
> rpc_server:tcpip = yes
> rpc_daemon:epmd = fork
> rpc_daemon:lsasd = fork
> 
> But I don't understand why it wasn't put to smb.conf directly.
> 
> The second problem is 'passdb backend'. I didn't find any documentation about 
> this module. An attempt to replace a file socket on net connection was 
> failed. And I had to make LDAP replication. It was easy, but " 
> ipa-replica-prepare" installed whole IPA server (tomcat, java, ldap), not 
> only ldap-server. I need to continue to read documentation. However the 
> problem was solved. 
> 
> 06.10.2016 23:51, Степаненко Алексей пишет:
>> Thank you for your reply. 
>> 
>> I've got Samba server for a company, accounts are created by hand. Clients 
>> are different windows or linux desktops. 
>> 
>> I want to install FreeIPA and have one area for managing accounts (SMB, 
>> SSH-access for others servers). Now, I prepare clean samba installation for 
>> testing. It would be great to use FreeIPA as authorization server for samba. 
>> 
>> I was looking for information about samba + freeIPA, but I found only this 
>> document. Maybe, I miss obvious things. 
>> 
>> 
>> 06.10.2016 20:31, Loris Santamaria пишет: 
>>> The document you are linking to explains how to configure a samba file 
>>> server in a freeipa domain, which is one of many ways you can configure 
>>> and use a samba server. 
>>> 
>>> What do you want to achieve with samba, and what is your current setup? 
>>> 
>>> 
>>> El jue, 06-10-2016 a las 19:23 +0300, Степаненко Алексей escribió: 
 Hello. 
 
 I've read the topic about FreeIPA and SAMBA 
 http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_Wit 
  
 h_IPA 
 
 If I understand clearly, samba's client must be present in 
 FreeIPA  AD. 
 Unfortunately, it does not work for me. I can't join some work 
 desktops 
 to AD. Is it possible to make Samba auth trough LDAP IPA ? Samba has 
 ldap support 
 
   ldap admin dn 
   ldap group suffix 
   ldap idmap suffix 
   ldap machine suffix 
   ldap passwd sync 
   ldap suffix 
   ldap user suffix 
 
 Does it work with IPA ? 
 
 Thanks. 
 
>> 
>> 
>> 
> 
> -- 
> 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

[Freeipa-users] IPA Client Install problems

2016-10-11 Thread Tyrell Jentink
First off...  new to the list, thank you in advance for your assistance!

My server is Fedora 24 Server, running in a VirtualBox virtual machine.  I
have FreeIPA Server 4.3.2-2.fc24, installed from the standard repositories,
and dnf says it's up to date. FreeIPA has a trust set up with an Windows
Server 2012r2 ActiveDirectory server, and it APPEARS to be working...

The first client I connected was a Raspberry Pi running Pidora.  This
client appears to have connected fine, and appears to be working (I guess I
haven't tried logging in as an ActiveDirectory user;  But it's certainly
NOT having any DNS issues, as other clients are; See below...)

Then I tried connecting a second client, a system running Fedora 24 with
FreeIPA Client 4.3.2-2.fc24, and the install went ALMOST according to
plan...  Here's the output of ipa-client-install:

> Discovery was successful!
> Client hostname: trainmaster.ipa.rxrhouse.net
> Realm: IPA.RXRHOUSE.NET
> DNS Domain: ipa.rxrhouse.net
> IPA Server: ipa-pdc.ipa.rxrhouse.net
> BaseDN: dc=ipa,dc=rxrhouse,dc=net
> Continue to configure the system with these values? [no]: yes
> Synchronizing time with KDC...
> Attempting to sync time using ntpd.  Will timeout after 15 seconds
> Attempting to sync time using ntpd.  Will timeout after 15 seconds
> Unable to sync time with NTP server, assuming the time is in sync. Please
> check
>
>that 123 UDP port is opened.
> User authorized to enroll computers: admin
> Password for ad...@ipa.rxrhouse.net:
> Successfully retrieved CA cert
> Subject: CN=Certificate Authority,O=IPA.RXRHOUSE.NET
> Issuer:  CN=Certificate Authority,O=IPA.RXRHOUSE.NET
> Valid From:  Thu Sep 08 17:27:47 2016 UTC
> Valid Until: Mon Sep 08 17:27:47 2036 UTC
> Enrolled in IPA realm IPA.RXRHOUSE.NET
> Created /etc/ipa/default.conf
> New SSSD config will be created
> Configured sudoers in /etc/nsswitch.conf
> Configured /etc/sssd/sssd.conf
> Configured /etc/krb5.conf for IPA realm IPA.RXRHOUSE.NET
> trying https://ipa-pdc.ipa.rxrhouse.net/ipa/json
> Forwarding 'ping' to json server '
> https://ipa-pdc.ipa.rxrhouse.net/ipa/json'
> Forwarding 'ca_is_enabled' to json server '
> https://ipa-pdc.ipa.rxrhouse.net/ipa/json'
> Systemwide CA database updated.
> Failed to update DNS records.
> Missing reverse record(s) for address(es): 10.42.0.100.
> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
> Forwarding 'host_mod' to json server '
> https://ipa-pdc.ipa.rxrhouse.net/ipa/json'
> Could not update DNS SSHFP records.
> SSSD enabled
> Configured /etc/openldap/ldap.conf
> NTP enabled
> Configured /etc/ssh/ssh_config
> Configured /etc/ssh/sshd_config
> Configuring ipa.rxrhouse.net as NIS domain.
> Client configuration complete.


Of concern, the installer failed to update DNS records, resulting in a
missing reverse record, and eventually failing to update the DNS SSHFP
records.  Looking in the Web UI for FreeIPA server, I see that the client
is registered, but it doesn't have any SSH keys , and as expected, doesn't
have a reverse zone...  But the Raspberry Pi DOES.

Just to be fully sure something was wrong...  I tried connecting with a
clean install of Fedora 24 running in a virtual machine, and had the same
issue.  I've googled around, and can't find anyone having any similar
issues...  And I didn't accidentally stumble across anything interesting
while exploring logs...  But I honestly don't know where to look.

TO BE CLEAR, things appear to work just fine from freeipa-client version
3.3.3-4.fc20  on pidora on a Raspberry Pi, but it's NOT working with the
latest versions from Fedora 24 on x86_64 hardware...

Where should I look first?  Thank you for any assistance...

--
Tyrell Jentink
-- 
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] Replication attrlist_replace nsslapd-referral failed

2016-10-11 Thread Fil Di Noto
Things have been working better (so far) after taking some steps I read here:

https://www.redhat.com/archives/freeipa-users/2016-January/msg00257.html



On Mon, Oct 10, 2016 at 6:48 PM, Fil Di Noto  wrote:
> After an IPA server is re-initialized it immediately begins failing
> incremental updates. I checked the kerberos logs and things appear to
> be ok there, I can manually test LDAP from all servers against all
> other servers.
>
> There is an DS5ReplicaBindDN entry in "dn:
> cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" for
> an IPA server that no longer exists. But all IPA living servers have
> an entry for all other living servers.
> There is the correct number of cn=master, and cn=ca, and the
> caRenewalMaster is set on the correct master.
>
>  "ipa-replica-manage del --force --clean " does not remove the entry.
>
> There were some RUV from the old servers also and I cleaned them. The
> man page says if a clean is run on the wrong ID then the server should
> be re-initialized, so I just did that on purpose and re-initialized
> the one of the servers and that has cleared the NSMMReplicationPlugin
> error (so far) but I am still getting the attrlist_replace error.
>
> I'm getting no indication of kerberos problems.Could it be the
> NSACLPlugin ? It preceeds the other error every time but that is
> probably just regular startup procedure, and having an ACL for
> something that doesn't exist doesn't feel like a fatal error to me. I
> didn't do the KRA install.
>
> [root@ipa05 slapd-example-com]# tail -f errors
> [10/Oct/2016:23:27:57 +] NSACLPlugin - The ACL target
> cn=vaults,cn=kra,dc=example,dc=com does not exist
> [10/Oct/2016:23:27:57 +] NSACLPlugin - The ACL target
> cn=casigningcert
> cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com does not
> exist
> [10/Oct/2016:23:27:57 +] agmt="cn=meToipa07.example.com"
> (ipa07:389) - Can't locate CSN 57fc2e7f000a000d in the changelog
> (DB rc=-30988). If replication stops, the consumer may need to be
> reinitialized.
> [10/Oct/2016:23:27:57 +] NSMMReplicationPlugin - changelog program
> - agmt="cn=meToipa07.example.com" (ipa07:389): CSN
> 57fc2e7f000a000d not found, we aren't as up to date, or we purged
> [10/Oct/2016:23:27:57 +] NSMMReplicationPlugin -
> agmt="cn=meToipa07.example.com" (ipa07:389): Data required to update
> replica has been purged. The replica must be reinitialized.
> [10/Oct/2016:23:27:57 +] NSMMReplicationPlugin -
> agmt="cn=meToipa07.example.com" (ipa07:389): Incremental update failed
> and requires administrator action
> [10/Oct/2016:23:29:09 +] attrlist_replace - attr_replace
> (nsslapd-referral, ldap://ipa07.example.com:389/o%3Dipaca) 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


Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-11 Thread John Popowitch
Ah, yes, thank you, Alexander.
I agree it would help if I followed the example better.
It would also help if I understood the example so a little description of what 
each command does would be very helpful.
It looks like that ACI record does exist.
Now how would I remove these LDAP records?


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com] 
Sent: Tuesday, October 11, 2016 2:44 PM
To: John Popowitch
Cc: Martin Basti; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors

On ti, 11 loka 2016, John Popowitch wrote:
>It doesn't look like there are any entries.
>
># ldapsearch -x -b 'cn=certprofiles,cn=ca,dc=aws,dc=cappex,dc=com' -s 
>base aci
'ldapsearch -x' is 'use simple authentication instead of SASL' -- given that 
you didn't specify any identity for simple authentication, you are running an 
anonymous search. Martin asked you to 'kinit' as administrator and then use 
SASL GSSAPI.

ACIs only available for retrieval to administrators. It is not a surprise that 
anonymous access does not see them.

It would be good if you would have followed the example:
>Here you have example
>
>kinit admin
>
>ldapsearch -Y GSSAPI -b 'cn=certprofiles,cn=ca,dc=,dc=' 
>-s base aci
>
>On 11.10.2016 17:48, John Popowitch wrote:
>Thanks, Martin.
>But I'm afraid you've gone beyond my level of LDAP knowledge.
>How would I check for that ACI?
>-John
>
>From: Martin Basti [mailto:mba...@redhat.com]
>Sent: Tuesday, October 11, 2016 10:38 AM
>To: John Popowitch; 
>freeipa-users@redhat.com
>Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to 
>run ipa-server-upgrade, but has errors
>
>
>
>
>On 11.10.2016 17:21, John Popowitch wrote:
>I agree that is weird.
>Several of the other managed permissions are updated successfully and they are 
>very similar.
>Yes, I can try to remove the permission manually.
>Is there any risk in corrupting or breaking the system?
>This is, I believe, one of three IPA servers in a multi-master replication.
>And we run our production website (basically our company) off of these servers.
>Assuming it's safe enough to do, could I delete that permission via the UI or 
>does it need to be directly via LDAP?
>
>Upgrade will re-create permission.
>
>You have to directly using LDAP as Directory Manager
>
>Also please check in: cn=certprofiles,cn=ca,$SUFFIX
>
>if you have this ACI there
>
>aci: (targetattr = "cn || description || 
>ipacertprofilestoreissued")(targetfil
> ter = "(objectclass=ipacertprofile)")(version 3.0;acl 
>"permission:System: Mod  ify Certificate Profile";allow (write) groupdn 
>= "ldap:///cn=System: Modify C  ertificate 
>Profile,cn=permissions,cn=pbac,dc=dom-058-017,dc=abc,dc=idm,dc=lab
> ,dc=eng,dc=brq,dc=redhat,dc=com";)
>
>This may also cause an issue, so if removing of permission itself did 
>not help (or permission does not exist) you may need to remove this ACI
>
>Martin
>
>
>
>
>From: Martin Basti [mailto:mba...@redhat.com]
>Sent: Tuesday, October 11, 2016 9:47 AM
>To: John Popowitch; 
>freeipa-users@redhat.com
>Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to 
>run ipa-server-upgrade, but has errors
>
>
>That's weird because the code is checking if a permission exists before 
>it tries to add a new one
>
>Can you try to remove 'System: Modify Certificate Profile' manually from LDAP 
>and re-run ipa-server-upgrade?
>
>
>
>On 11.10.2016 15:53, John Popowitch wrote:
>2016-10-10T19:51:38Z DEBUG Updating managed permission: System: Modify 
>Certificate Profile 2016-10-10T19:51:38Z DEBUG Destroyed connection 
>context.ldap2_82077392 2016-10-10T19:51:38Z ERROR Upgrade failed with 
>This entry already exists 2016-10-10T19:51:38Z DEBUG Traceback (most recent 
>call last):
>  File 
> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 
> 306, in __upgrade
>self.modified = (ld.update(self.files) or self.modified)
>  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", 
> line 905, in update
>self._run_updates(all_updates)
>  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", 
> line 877, in _run_updates
>self._run_update_plugin(update['plugin'])
>  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", 
> line 852, in _run_update_plugin
>restart_ds, updates = self.api.Updater[plugin_name]()
>  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1400, in 
> __call__
>return self.execute(**options)
> File 
> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
>  line 433, in execute
>anonymous_read_aci)
>  File 
> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
>  line 529, in update_permission
>ldap.add_entry(entry)
>  File 

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-11 Thread Alexander Bokovoy

On ti, 11 loka 2016, John Popowitch wrote:

It doesn't look like there are any entries.

# ldapsearch -x -b 'cn=certprofiles,cn=ca,dc=aws,dc=cappex,dc=com' -s base aci

'ldapsearch -x' is 'use simple authentication instead of SASL' -- given
that you didn't specify any identity for simple authentication, you are
running an anonymous search. Martin asked you to 'kinit' as
administrator and then use SASL GSSAPI.

ACIs only available for retrieval to administrators. It is not a
surprise that anonymous access does not see them.

It would be good if you would have followed the example:

Here you have example

kinit admin

ldapsearch -Y GSSAPI -b 'cn=certprofiles,cn=ca,dc=,dc=' -s base 
aci

On 11.10.2016 17:48, John Popowitch wrote:
Thanks, Martin.
But I'm afraid you've gone beyond my level of LDAP knowledge.
How would I check for that ACI?
-John

From: Martin Basti [mailto:mba...@redhat.com]
Sent: Tuesday, October 11, 2016 10:38 AM
To: John Popowitch; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors




On 11.10.2016 17:21, John Popowitch wrote:
I agree that is weird.
Several of the other managed permissions are updated successfully and they are 
very similar.
Yes, I can try to remove the permission manually.
Is there any risk in corrupting or breaking the system?
This is, I believe, one of three IPA servers in a multi-master replication.
And we run our production website (basically our company) off of these servers.
Assuming it's safe enough to do, could I delete that permission via the UI or 
does it need to be directly via LDAP?

Upgrade will re-create permission.

You have to directly using LDAP as Directory Manager

Also please check in: cn=certprofiles,cn=ca,$SUFFIX

if you have this ACI there

aci: (targetattr = "cn || description || ipacertprofilestoreissued")(targetfil
ter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Mod
ify Certificate Profile";allow (write) groupdn = 
"ldap:///cn=System: Modify C
ertificate Profile,cn=permissions,cn=pbac,dc=dom-058-017,dc=abc,dc=idm,dc=lab
,dc=eng,dc=brq,dc=redhat,dc=com";)

This may also cause an issue, so if removing of permission itself did not help 
(or permission does not exist) you may need to remove this ACI

Martin




From: Martin Basti [mailto:mba...@redhat.com]
Sent: Tuesday, October 11, 2016 9:47 AM
To: John Popowitch; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors


That's weird because the code is checking if a permission exists before it 
tries to add a new one

Can you try to remove 'System: Modify Certificate Profile' manually from LDAP 
and re-run ipa-server-upgrade?



On 11.10.2016 15:53, John Popowitch wrote:
2016-10-10T19:51:38Z DEBUG Updating managed permission: System: Modify 
Certificate Profile
2016-10-10T19:51:38Z DEBUG Destroyed connection context.ldap2_82077392
2016-10-10T19:51:38Z ERROR Upgrade failed with This entry already exists
2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):
 File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", 
line 306, in __upgrade
   self.modified = (ld.update(self.files) or self.modified)
 File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
905, in update
   self._run_updates(all_updates)
 File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
877, in _run_updates
   self._run_update_plugin(update['plugin'])
 File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
852, in _run_update_plugin
   restart_ds, updates = self.api.Updater[plugin_name]()
 File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1400, in 
__call__
   return self.execute(**options)
File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
 line 433, in execute
   anonymous_read_aci)
 File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
 line 529, in update_permission
   ldap.add_entry(entry)
 File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1428, in 
add_entry
   self.conn.add_s(str(entry.dn), 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 938, in 
error_handler
   raise errors.DuplicateEntry()
DuplicateEntry: This entry already exists

2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):
 File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
418, in start_creation
   run_step(full_msg, method)
 File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
408, in run_step
   method()
File 

[Freeipa-users] bind-dyndb-ldap issues

2016-10-11 Thread Brendan Kearney
i am using bind-dyndb-ldap on fedora 24 without FreeIPA, and continue to 
have my logs swamped with errors about "check failed" from settings.c 
and fwd.c.  i am completely up to date with every package, so the latest 
versions of everything are installed.


[settings.c : 420: setting_update_from_ldap_entry] check failed: ignore
[settings.c : 436: setting_update_from_ldap_entry] check failed: ignore
[fwd.c : 378: fwd_setting_isexplicit] check failed: not found

i have two boxes running a named instance each, in a "master/master" 
config.  each has the zone data configured per below.  the uri refers to 
the local ip of each server.


dynamic-db "bpk2.com" {
library "ldap.so";
arg "uri ldap://192.168.88.1/;;
arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com";
arg "auth_method simple";
arg "bind_dn cn=dnsUser,dc=bpk2,dc=com";
arg "password dnsPass";

arg "fake_mname server1.bpk2.com.";
arg "dyn_update yes";
arg "connections 2";
arg "verbose_checks yes";
};

zone "." IN {
type hint;
file "named.ca";
};

include "/etc/named.rfc1912.zones";

my dns container is defined in openldap as such:

dn: cn=dns,ou=Daemons,dc=bpk2,dc=com
cn: dns
idnspersistentsearch: FALSE
idnszonerefresh: 30
objectclass: top
objectclass: nsContainer
objectclass: idnsConfigObject

where and how can i find the source of my issue?  these issues are 
causing performance issues on the rest of my network.  because of these 
errors, ldap throws errors about deferred operations for binding, too 
many executing, and pending operations.  additionally, recursion also 
seems to be impacted.  this is noticed most when streaming content.  
buffering, stuttering and pixelation are seen in the video streams.  it 
could be the swamping of logs killing I/O or the actual recurision, but 
100% the video issues are related.  the log events match up exactly with 
the buffering.


i had this issue with bind-dyndb-ldap and fedora 20 up until i recently 
upgraded.  i went from F20 to F24, and put things on nice new SSDs, 
instead of spinning disks.  the problem followed the upgrade.  are there 
configuration items i am missing?  are there tweaks i can do to improve 
something?  how do i get rid of these errors, so dns performance (or the 
log swamping) is not affecting the rest of my network?


thank you,

brendan

--
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] Password Complexity Requirements Seems Insufficient

2016-10-11 Thread Bennett, Chip
I just joined this list, so if this question has been asked before (and I'll 
bet it has), I apologize in advance.

A google search was unrevealing, so I'm asking here: we're running FreeIPA 
Version 3.0.0 on CentOS 6.6.   It looks like the password complexity 
requirements are limited to setting the number of character classes to require, 
i.e. setting it to "2" would require your new password to be any two of the 
character classes.

What if you wanted new passwords to meet specific class requirements, i.e. a 
mix of UL, LC, and numbers.  It looks like you would use a value of "3" to 
accomplish this, but that would also allow UC, LC, and special, or LC, numbers, 
and special, but you don't want to allow the those:  how would you specify that?

Also, what if you had a requirement for more than one of the character classes, 
i.e. you want to require two UC characters or two special characters?

Thanks in advance for the help,
Chip Bennett


This message is solely for the intended recipient(s) and may contain 
confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.-- 
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 v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-11 Thread Martin Basti

Here you have example

kinit admin

ldapsearch -Y GSSAPI -b 'cn=certprofiles,cn=ca,dc=,dc=' -s 
base aci



On 11.10.2016 17:48, John Popowitch wrote:


Thanks, Martin.

But I'm afraid you've gone beyond my level of LDAP knowledge.

How would I check for that ACI?

-John

*From:*Martin Basti [mailto:mba...@redhat.com]
*Sent:* Tuesday, October 11, 2016 10:38 AM
*To:* John Popowitch; freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me 
to run ipa-server-upgrade, but has errors


On 11.10.2016 17:21, John Popowitch wrote:

I agree that is weird.

Several of the other managed permissions are updated successfully
and they are very similar.

Yes, I can try to remove the permission manually.

Is there any risk in corrupting or breaking the system?
This is, I believe, one of three IPA servers in a multi-master
replication.

And we run our production website (basically our company) off of
these servers.

Assuming it's safe enough to do, could I delete that permission
via the UI or does it need to be directly via LDAP?


Upgrade will re-create permission.

You have to directly using LDAP as Directory Manager

Also please check in: cn=certprofiles,cn=ca,$SUFFIX

if you have this ACI there

aci: (targetattr = "cn || description || 
ipacertprofilestoreissued")(targetfil
 ter = "(objectclass=ipacertprofile)")(version 3.0;acl 
"permission:System: Mod
 ify Certificate Profile";allow (write) groupdn = "ldap:///cn=System 
: Modify C
 ertificate 
Profile,cn=permissions,cn=pbac,dc=dom-058-017,dc=abc,dc=idm,dc=lab

 ,dc=eng,dc=brq,dc=redhat,dc=com";)

This may also cause an issue, so if removing of permission itself did 
not help (or permission does not exist) you may need to remove this ACI


Martin


*From:*Martin Basti [mailto:mba...@redhat.com]
*Sent:* Tuesday, October 11, 2016 9:47 AM
*To:* John Popowitch; freeipa-users@redhat.com 

*Subject:* Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me 
to run ipa-server-upgrade, but has errors


That's weird because the code is checking if a permission exists 
before it tries to add a new one


Can you try to remove 'System: Modify Certificate Profile' manually 
from LDAP and re-run ipa-server-upgrade?


On 11.10.2016 15:53, John Popowitch wrote:

2016-10-10T19:51:38Z DEBUG Updating managed permission: System:
Modify Certificate Profile

2016-10-10T19:51:38Z DEBUG Destroyed connection context.ldap2_82077392

2016-10-10T19:51:38Z ERROR Upgrade failed with This entry already
exists

2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py",
line 306, in __upgrade

self.modified = (ld.update(self.files) or self.modified)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py",
line 905, in update

self._run_updates(all_updates)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py",
line 877, in _run_updates

self._run_update_plugin(update['plugin'])

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py",
line 852, in _run_update_plugin

restart_ds, updates = self.api.Updater[plugin_name]()

  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line
1400, in __call__

return self.execute(**options)

 File

"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
line 433, in execute

anonymous_read_aci)

  File

"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
line 529, in update_permission

ldap.add_entry(entry)

  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py",
line 1428, in add_entry

self.conn.add_s(str(entry.dn), 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 938, in error_handler

raise errors.DuplicateEntry()

DuplicateEntry: This entry already exists

2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 418, in start_creation

run_step(full_msg, method)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 408, in run_step

method()

 File
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py",
line 314, in __upgrade

raise RuntimeError(e)

RuntimeError: This entry already exists

2016-10-10T19:51:38Z DEBUG   [error] RuntimeError: This entry
already exists

2016-10-10T19:51:38Z DEBUG   [cleanup]: stopping directory server

2016-10-10T19:51:38Z DEBUG Starting external 

[Freeipa-users] Different Database Generation ID

2016-10-11 Thread Ian Harding
I have this error in the log of my FreeIPA server freeipa-sea.bpt.rocks:

[11/Oct/2016:09:04:39 -0700] NSMMReplicationPlugin -
agmt="cn=masterAgreement1-seattlenfs.bpt.rocks-pki-tomcat"
(seattlenfs:389): The remote replica has a different database generation
ID than the local database.  You may have to reinitialize the remote
replica, or the local replica.

So I did this:

ipa-replica-manage re-initialize --from freeipa-sea.bpt.rocks

on seattlenfs

But the error continues.

I think I know why.  freeipa-sea had a meltdown and I had to rebuild it,
and established it as a replica of seattlenfs.  Unfortunately, I think
seattlenfs was a replica of the original freeipa-sea.

It seems like a bad idea to reinitialize themselves from each other, and
in fact it's warned against here:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Troubleshooting_Replication_Related_Problems.html

"... Also, M2 should not initialize M1 back. "

But in looking at my bash history I have indeed done that as well.

Is there any way out of this mess?  These two servers actually DO
replicate, most of the time.  They stop for no reason and restarting the
ipa services on freeipa-sea does get them started again.

-- 

Ian Harding
IT Director
Brown Paper Tickets
1-800-838-3006 ext 7186
http://www.brownpapertickets.com

-- 
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 v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-11 Thread John Popowitch
Thanks, Martin.
But I'm afraid you've gone beyond my level of LDAP knowledge.
How would I check for that ACI?
-John

From: Martin Basti [mailto:mba...@redhat.com]
Sent: Tuesday, October 11, 2016 10:38 AM
To: John Popowitch; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors




On 11.10.2016 17:21, John Popowitch wrote:
I agree that is weird.
Several of the other managed permissions are updated successfully and they are 
very similar.
Yes, I can try to remove the permission manually.
Is there any risk in corrupting or breaking the system?
This is, I believe, one of three IPA servers in a multi-master replication.
And we run our production website (basically our company) off of these servers.
Assuming it's safe enough to do, could I delete that permission via the UI or 
does it need to be directly via LDAP?

Upgrade will re-create permission.

You have to directly using LDAP as Directory Manager

Also please check in: cn=certprofiles,cn=ca,$SUFFIX

if you have this ACI there

aci: (targetattr = "cn || description || ipacertprofilestoreissued")(targetfil
 ter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Mod
 ify Certificate Profile";allow (write) groupdn = 
"ldap:///cn=System: Modify C
 ertificate Profile,cn=permissions,cn=pbac,dc=dom-058-017,dc=abc,dc=idm,dc=lab
 ,dc=eng,dc=brq,dc=redhat,dc=com";)

This may also cause an issue, so if removing of permission itself did not help 
(or permission does not exist) you may need to remove this ACI

Martin



From: Martin Basti [mailto:mba...@redhat.com]
Sent: Tuesday, October 11, 2016 9:47 AM
To: John Popowitch; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors


That's weird because the code is checking if a permission exists before it 
tries to add a new one

Can you try to remove 'System: Modify Certificate Profile' manually from LDAP 
and re-run ipa-server-upgrade?



On 11.10.2016 15:53, John Popowitch wrote:
2016-10-10T19:51:38Z DEBUG Updating managed permission: System: Modify 
Certificate Profile
2016-10-10T19:51:38Z DEBUG Destroyed connection context.ldap2_82077392
2016-10-10T19:51:38Z ERROR Upgrade failed with This entry already exists
2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", 
line 306, in __upgrade
self.modified = (ld.update(self.files) or self.modified)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
905, in update
self._run_updates(all_updates)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
877, in _run_updates
self._run_update_plugin(update['plugin'])
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
852, in _run_update_plugin
restart_ds, updates = self.api.Updater[plugin_name]()
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1400, in 
__call__
return self.execute(**options)
 File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
 line 433, in execute
anonymous_read_aci)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
 line 529, in update_permission
ldap.add_entry(entry)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1428, in 
add_entry
self.conn.add_s(str(entry.dn), 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 938, in 
error_handler
raise errors.DuplicateEntry()
DuplicateEntry: This entry already exists

2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
418, in start_creation
run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
408, in run_step
method()
 File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", 
line 314, in __upgrade
raise RuntimeError(e)
RuntimeError: This entry already exists

2016-10-10T19:51:38Z DEBUG   [error] RuntimeError: This entry already exists
2016-10-10T19:51:38Z DEBUG   [cleanup]: stopping directory server
2016-10-10T19:51:38Z DEBUG Starting external process
2016-10-10T19:51:38Z DEBUG args='/bin/systemctl' 'stop' 
'dirsrv@AWS-CAPPEX-COM.service'
2016-10-10T19:51:40Z DEBUG Process finished, return code=0
2016-10-10T19:51:40Z DEBUG stdout=
2016-10-10T19:51:40Z DEBUG stderr=
2016-10-10T19:51:40Z DEBUG   duration: 1 seconds
2016-10-10T19:51:40Z DEBUG   [cleanup]: restoring configuration
2016-10-10T19:51:40Z DEBUG Loading StateFile from 

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-11 Thread Martin Basti



On 11.10.2016 17:21, John Popowitch wrote:


I agree that is weird.

Several of the other managed permissions are updated successfully and 
they are very similar.


Yes, I can try to remove the permission manually.

Is there any risk in corrupting or breaking the system?
This is, I believe, one of three IPA servers in a multi-master 
replication.


And we run our production website (basically our company) off of these 
servers.


Assuming it's safe enough to do, could I delete that permission via 
the UI or does it need to be directly via LDAP?




Upgrade will re-create permission.

You have to directly using LDAP as Directory Manager

Also please check in: cn=certprofiles,cn=ca,$SUFFIX

if you have this ACI there

aci: (targetattr = "cn || description || 
ipacertprofilestoreissued")(targetfil
 ter = "(objectclass=ipacertprofile)")(version 3.0;acl 
"permission:System: Mod
 ify Certificate Profile";allow (write) groupdn = "ldap:///cn=System: 
Modify C
 ertificate 
Profile,cn=permissions,cn=pbac,dc=dom-058-017,dc=abc,dc=idm,dc=lab

 ,dc=eng,dc=brq,dc=redhat,dc=com";)

This may also cause an issue, so if removing of permission itself did 
not help (or permission does not exist) you may need to remove this ACI


Martin


*From:*Martin Basti [mailto:mba...@redhat.com]
*Sent:* Tuesday, October 11, 2016 9:47 AM
*To:* John Popowitch; freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me 
to run ipa-server-upgrade, but has errors


That's weird because the code is checking if a permission exists 
before it tries to add a new one


Can you try to remove 'System: Modify Certificate Profile' manually 
from LDAP and re-run ipa-server-upgrade?


On 11.10.2016 15:53, John Popowitch wrote:

2016-10-10T19:51:38Z DEBUG Updating managed permission: System:
Modify Certificate Profile

2016-10-10T19:51:38Z DEBUG Destroyed connection context.ldap2_82077392

2016-10-10T19:51:38Z ERROR Upgrade failed with This entry already
exists

2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py",
line 306, in __upgrade

self.modified = (ld.update(self.files) or self.modified)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py",
line 905, in update

self._run_updates(all_updates)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py",
line 877, in _run_updates

self._run_update_plugin(update['plugin'])

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py",
line 852, in _run_update_plugin

restart_ds, updates = self.api.Updater[plugin_name]()

  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line
1400, in __call__

return self.execute(**options)

 File

"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
line 433, in execute

anonymous_read_aci)

  File

"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
line 529, in update_permission

ldap.add_entry(entry)

  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py",
line 1428, in add_entry

self.conn.add_s(str(entry.dn), 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 938, in error_handler

raise errors.DuplicateEntry()

DuplicateEntry: This entry already exists

2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 418, in start_creation

run_step(full_msg, method)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 408, in run_step

method()

 File
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py",
line 314, in __upgrade

raise RuntimeError(e)

RuntimeError: This entry already exists

2016-10-10T19:51:38Z DEBUG   [error] RuntimeError: This entry
already exists

2016-10-10T19:51:38Z DEBUG   [cleanup]: stopping directory server

2016-10-10T19:51:38Z DEBUG Starting external process

2016-10-10T19:51:38Z DEBUG args='/bin/systemctl' 'stop'
'dirsrv@AWS-CAPPEX-COM.service '

2016-10-10T19:51:40Z DEBUG Process finished, return code=0

2016-10-10T19:51:40Z DEBUG stdout=

2016-10-10T19:51:40Z DEBUG stderr=

2016-10-10T19:51:40Z DEBUG   duration: 1 seconds

2016-10-10T19:51:40Z DEBUG   [cleanup]: restoring configuration

2016-10-10T19:51:40Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'

2016-10-10T19:51:40Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'

 

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-11 Thread John Popowitch
I agree that is weird.
Several of the other managed permissions are updated successfully and they are 
very similar.
Yes, I can try to remove the permission manually.
Is there any risk in corrupting or breaking the system?
This is, I believe, one of three IPA servers in a multi-master replication.
And we run our production website (basically our company) off of these servers.
Assuming it's safe enough to do, could I delete that permission via the UI or 
does it need to be directly via LDAP?

From: Martin Basti [mailto:mba...@redhat.com]
Sent: Tuesday, October 11, 2016 9:47 AM
To: John Popowitch; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors


That's weird because the code is checking if a permission exists before it 
tries to add a new one

Can you try to remove 'System: Modify Certificate Profile' manually from LDAP 
and re-run ipa-server-upgrade?



On 11.10.2016 15:53, John Popowitch wrote:
2016-10-10T19:51:38Z DEBUG Updating managed permission: System: Modify 
Certificate Profile
2016-10-10T19:51:38Z DEBUG Destroyed connection context.ldap2_82077392
2016-10-10T19:51:38Z ERROR Upgrade failed with This entry already exists
2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", 
line 306, in __upgrade
self.modified = (ld.update(self.files) or self.modified)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
905, in update
self._run_updates(all_updates)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
877, in _run_updates
self._run_update_plugin(update['plugin'])
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
852, in _run_update_plugin
restart_ds, updates = self.api.Updater[plugin_name]()
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1400, in 
__call__
return self.execute(**options)
 File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
 line 433, in execute
anonymous_read_aci)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
 line 529, in update_permission
ldap.add_entry(entry)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1428, in 
add_entry
self.conn.add_s(str(entry.dn), 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 938, in 
error_handler
raise errors.DuplicateEntry()
DuplicateEntry: This entry already exists

2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
418, in start_creation
run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
408, in run_step
method()
 File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", 
line 314, in __upgrade
raise RuntimeError(e)
RuntimeError: This entry already exists

2016-10-10T19:51:38Z DEBUG   [error] RuntimeError: This entry already exists
2016-10-10T19:51:38Z DEBUG   [cleanup]: stopping directory server
2016-10-10T19:51:38Z DEBUG Starting external process
2016-10-10T19:51:38Z DEBUG args='/bin/systemctl' 'stop' 
'dirsrv@AWS-CAPPEX-COM.service'
2016-10-10T19:51:40Z DEBUG Process finished, return code=0
2016-10-10T19:51:40Z DEBUG stdout=
2016-10-10T19:51:40Z DEBUG stderr=
2016-10-10T19:51:40Z DEBUG   duration: 1 seconds
2016-10-10T19:51:40Z DEBUG   [cleanup]: restoring configuration
2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Saving StateFile to 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Saving StateFile to 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG   duration: 0 seconds
2016-10-10T19:51:40Z ERROR IPA server upgrade failed: Inspect 
/var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2016-10-10T19:51:40Z 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/ipaserver/install/ipa_server_upgrade.py", 
line 50, in run
raise admintool.ScriptError(str(e))

2016-10-10T19:51:40Z DEBUG The ipa-server-upgrade command failed, exception: 
ScriptError: 

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-11 Thread Martin Basti
That's weird because the code is checking if a permission exists before 
it tries to add a new one


Can you try to remove 'System: Modify Certificate Profile' manually from 
LDAP and re-run ipa-server-upgrade?




On 11.10.2016 15:53, John Popowitch wrote:


2016-10-10T19:51:38Z DEBUG Updating managed permission: System: Modify 
Certificate Profile


2016-10-10T19:51:38Z DEBUG Destroyed connection context.ldap2_82077392

2016-10-10T19:51:38Z ERROR Upgrade failed with This entry already exists

2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):

  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", 
line 306, in __upgrade


self.modified = (ld.update(self.files) or self.modified)

  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", 
line 905, in update


self._run_updates(all_updates)

  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", 
line 877, in _run_updates


self._run_update_plugin(update['plugin'])

  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", 
line 852, in _run_update_plugin


restart_ds, updates = self.api.Updater[plugin_name]()

  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 
1400, in __call__


return self.execute(**options)

 File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py", 
line 433, in execute


anonymous_read_aci)

  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py", 
line 529, in update_permission


ldap.add_entry(entry)

  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 
1428, in add_entry


self.conn.add_s(str(entry.dn), 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 
938, in error_handler


raise errors.DuplicateEntry()

DuplicateEntry: This entry already exists

2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):

  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
418, in start_creation


run_step(full_msg, method)

  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
408, in run_step


method()

 File 
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", 
line 314, in __upgrade


raise RuntimeError(e)

RuntimeError: This entry already exists

2016-10-10T19:51:38Z DEBUG   [error] RuntimeError: This entry already 
exists


2016-10-10T19:51:38Z DEBUG   [cleanup]: stopping directory server

2016-10-10T19:51:38Z DEBUG Starting external process

2016-10-10T19:51:38Z DEBUG args='/bin/systemctl' 'stop' 
'dirsrv@AWS-CAPPEX-COM.service'


2016-10-10T19:51:40Z DEBUG Process finished, return code=0

2016-10-10T19:51:40Z DEBUG stdout=

2016-10-10T19:51:40Z DEBUG stderr=

2016-10-10T19:51:40Z DEBUG   duration: 1 seconds

2016-10-10T19:51:40Z DEBUG   [cleanup]: restoring configuration

2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'


2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'


2016-10-10T19:51:40Z DEBUG Saving StateFile to 
'/var/lib/ipa/sysrestore/sysrestore.state'


2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'


2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'


2016-10-10T19:51:40Z DEBUG Saving StateFile to 
'/var/lib/ipa/sysrestore/sysrestore.state'


2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'


2016-10-10T19:51:40Z DEBUG   duration: 0 seconds

2016-10-10T19:51:40Z ERROR IPA server upgrade failed: Inspect 
/var/log/ipaupgrade.log and run command ipa-server-upgrade manually.


2016-10-10T19:51:40Z 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/ipaserver/install/ipa_server_upgrade.py", 
line 50, in run


raise admintool.ScriptError(str(e))

2016-10-10T19:51:40Z DEBUG The ipa-server-upgrade command failed, 
exception: ScriptError: ('IPA upgrade failed.', 1)


2016-10-10T19:51:40Z ERROR ('IPA upgrade failed.', 1)

*From:*Martin Basti [mailto:mba...@redhat.com]
*Sent:* Tuesday, October 11, 2016 1:53 AM
*To:* John Popowitch; freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me 
to run ipa-server-upgrade, but has errors


On 10.10.2016 23:30, John Popowitch wrote:

Hello FreeIPA community.

I've inherited a group of three FreeIPA v4.2 servers on CentOS 7.2.

I had to reboot one of the servers and now IPA won't run saying,
"Upgrade required: please run ipa-server-upgrade command."

But when I run ipa-server-upgrade I get an error:

ipa: ERROR: Upgrade failed with This entry already 

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-11 Thread John Popowitch
2016-10-10T19:51:38Z DEBUG Updating managed permission: System: Modify 
Certificate Profile
2016-10-10T19:51:38Z DEBUG Destroyed connection context.ldap2_82077392
2016-10-10T19:51:38Z ERROR Upgrade failed with This entry already exists
2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", 
line 306, in __upgrade
self.modified = (ld.update(self.files) or self.modified)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
905, in update
self._run_updates(all_updates)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
877, in _run_updates
self._run_update_plugin(update['plugin'])
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 
852, in _run_update_plugin
restart_ds, updates = self.api.Updater[plugin_name]()
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1400, in 
__call__
return self.execute(**options)
 File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
 line 433, in execute
anonymous_read_aci)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py",
 line 529, in update_permission
ldap.add_entry(entry)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1428, in 
add_entry
self.conn.add_s(str(entry.dn), 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 938, in 
error_handler
raise errors.DuplicateEntry()
DuplicateEntry: This entry already exists

2016-10-10T19:51:38Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
418, in start_creation
run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
408, in run_step
method()
 File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", 
line 314, in __upgrade
raise RuntimeError(e)
RuntimeError: This entry already exists

2016-10-10T19:51:38Z DEBUG   [error] RuntimeError: This entry already exists
2016-10-10T19:51:38Z DEBUG   [cleanup]: stopping directory server
2016-10-10T19:51:38Z DEBUG Starting external process
2016-10-10T19:51:38Z DEBUG args='/bin/systemctl' 'stop' 
'dirsrv@AWS-CAPPEX-COM.service'
2016-10-10T19:51:40Z DEBUG Process finished, return code=0
2016-10-10T19:51:40Z DEBUG stdout=
2016-10-10T19:51:40Z DEBUG stderr=
2016-10-10T19:51:40Z DEBUG   duration: 1 seconds
2016-10-10T19:51:40Z DEBUG   [cleanup]: restoring configuration
2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Saving StateFile to 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Saving StateFile to 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-10-10T19:51:40Z DEBUG   duration: 0 seconds
2016-10-10T19:51:40Z ERROR IPA server upgrade failed: Inspect 
/var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2016-10-10T19:51:40Z 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/ipaserver/install/ipa_server_upgrade.py", 
line 50, in run
raise admintool.ScriptError(str(e))

2016-10-10T19:51:40Z DEBUG The ipa-server-upgrade command failed, exception: 
ScriptError: ('IPA upgrade failed.', 1)
2016-10-10T19:51:40Z ERROR ('IPA upgrade failed.', 1)



From: Martin Basti [mailto:mba...@redhat.com]
Sent: Tuesday, October 11, 2016 1:53 AM
To: John Popowitch; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors




On 10.10.2016 23:30, John Popowitch wrote:
Hello FreeIPA community.
I've inherited a group of three FreeIPA v4.2 servers on CentOS 7.2.
I had to reboot one of the servers and now IPA won't run saying, "Upgrade 
required: please run ipa-server-upgrade command."
But when I run ipa-server-upgrade I get an error:
ipa: ERROR: Upgrade failed with This entry already exists
When I run it in debug mode the last action before the error is:
ipa.ipaserver.install.plugins.update_managed_permissions.update_managed_permissions:
 DEBUG: Updating managed permission: System: Modify Certificate Profile
It appears that several of the other managed permissions are processed 
successfully.
When I look in the UI on one of 

Re: [Freeipa-users] sssd 1.14.1, HBAC still not working?

2016-10-11 Thread Jakub Hrozek
On Tue, Oct 11, 2016 at 03:28:55PM +1100, Lachlan Musicman wrote:
> After further testing, I've discovered that the dev system wasn't working
> as well as I thought it was: HBAC and sshd don't seem to be playing well
> together on one server, but fine on the other?
> 
> ie, I can run the same commands from both ipa-server and ipa-client:
> 
> ipa hbactest  --user=user1 --host=ipa-server.unixdev.petermac.org.au
> --service=sshd
> ipa hbactest  --user=user1 --host=ipa-client.unixdev.petermac.org.au
> --service=sshd
> 
> 
> and every response is:
> 
> to the ipa-client
> 
> Access granted: True
> 
>   Matched rules: Admin Users (w sudo)
>   Matched rules: Users
> 
> to the ipa-server
> 
> Access granted: True
> 
>   Matched rules: Cluster Admin Users (sudo)
>   Not matched rules: Cluster Users
> 
> 
> but when I try to login to the ipa-server, I get an instance disconnect? I
> can login happily to the ipa-client no problems.
> 
> Is there a special rule about sshd and the ipa-server?

No, there shouldn't be. Can you generate sssd logs on the instance that
is acting up and send them to me? It's best to run date and expire the
cache before the test as well:
sss_cache -E; date; ssh user@host; date
so that we can cross-check the logs knowing the time of the test. If you
don't mind I'd like to share the logs with other SSSD developers because
I think I already tried to look into this issue and couldn't find the root
cause in the past, so maybe others will spot something..

-- 
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] Replication attrlist_replace nsslapd-referral failed

2016-10-11 Thread Ludwig Krispenz

Hi,

you don't specify the version you are using:
If it is 389-ds-base-1.3.4.0-33.el7_2.x86_64
the following may apply:
>>>
we have identified an issue with this version, it includes a fix for 
389-ds ticket #48766, which was incomplete and resolved shortly after 
the release of this version (it is missing the latest patch for #49766 
and for #48954).
You can try to go back to 1.3.4.0-32 or if you have support get a hotfix 
from our support.

<<<

Sorry for this,
On 10/11/2016 03:48 AM, Fil Di Noto wrote:

After an IPA server is re-initialized it immediately begins failing
incremental updates. I checked the kerberos logs and things appear to
be ok there, I can manually test LDAP from all servers against all
other servers.

There is an DS5ReplicaBindDN entry in "dn:
cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" for
an IPA server that no longer exists. But all IPA living servers have
an entry for all other living servers.
There is the correct number of cn=master, and cn=ca, and the
caRenewalMaster is set on the correct master.

  "ipa-replica-manage del --force --clean " does not remove the entry.

There were some RUV from the old servers also and I cleaned them. The
man page says if a clean is run on the wrong ID then the server should
be re-initialized, so I just did that on purpose and re-initialized
the one of the servers and that has cleared the NSMMReplicationPlugin
error (so far) but I am still getting the attrlist_replace error.

I'm getting no indication of kerberos problems.Could it be the
NSACLPlugin ? It preceeds the other error every time but that is
probably just regular startup procedure, and having an ACL for
something that doesn't exist doesn't feel like a fatal error to me. I
didn't do the KRA install.

[root@ipa05 slapd-example-com]# tail -f errors
[10/Oct/2016:23:27:57 +] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=example,dc=com does not exist
[10/Oct/2016:23:27:57 +] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com does not
exist
[10/Oct/2016:23:27:57 +] agmt="cn=meToipa07.example.com"
(ipa07:389) - Can't locate CSN 57fc2e7f000a000d in the changelog
(DB rc=-30988). If replication stops, the consumer may need to be
reinitialized.
[10/Oct/2016:23:27:57 +] NSMMReplicationPlugin - changelog program
- agmt="cn=meToipa07.example.com" (ipa07:389): CSN
57fc2e7f000a000d not found, we aren't as up to date, or we purged
[10/Oct/2016:23:27:57 +] NSMMReplicationPlugin -
agmt="cn=meToipa07.example.com" (ipa07:389): Data required to update
replica has been purged. The replica must be reinitialized.
[10/Oct/2016:23:27:57 +] NSMMReplicationPlugin -
agmt="cn=meToipa07.example.com" (ipa07:389): Incremental update failed
and requires administrator action
[10/Oct/2016:23:29:09 +] attrlist_replace - attr_replace
(nsslapd-referral, ldap://ipa07.example.com:389/o%3Dipaca) failed.



--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

--
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 v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-11 Thread Martin Basti



On 10.10.2016 23:30, John Popowitch wrote:


Hello FreeIPA community.

I've inherited a group of three FreeIPA v4.2 servers on CentOS 7.2.

I had to reboot one of the servers and now IPA won't run saying, 
"Upgrade required: please run ipa-server-upgrade command."


But when I run ipa-server-upgrade I get an error:

ipa: ERROR: Upgrade failed with This entry already exists

When I run it in debug mode the last action before the error is:

ipa.ipaserver.install.plugins.update_managed_permissions.update_managed_permissions: 
DEBUG: Updating managed permission: System: Modify Certificate Profile


It appears that several of the other managed permissions are processed 
successfully.


When I look in the UI on one of the other servers it appears that this 
permission exists under IPA Server -> Role Based Access Control -> 
Permissions.


I'm not familiar with FreeIPA so any help would be greatly appreciated.

Thanks in advance.

-John





Hello,

can you post the related part of ipaupgrade.log here?

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