Re: [Freeipa-users] FreeIPA as Samba Backend, Existing Users Fail

[Youenn PIOLET]

Hi,

ipa-adtrust-install populates the ipaNTHash in LDAP for each user/group,
but you still need a samba backend to read these new attributes.
Do you use ipasam.so ?
If you don't, you should recompile your version of FreeIPA, move ipasam.so
to your password backend directory containing other .so files, and put this
in your smb.conf :

passdb backend = ldapsam:ldap//ipaserver


Procedure / best practices may have change now, if anyone from redhat is
around to confirm...
I just can tell it's working with any Centos 7 and FreeIPA > 4.1.4 server.

--
Youenn Piolet
piole...@gmail.com


2017-01-13 19:33 GMT+01:00 Armaan Esfahani :

> Upon running the ldapmodify command, I receive an “ldap_bind: No such
> object (32)” error, any suggesions?
>
>
>
> On 1/13/17, 8:37 AM, "Sumit Bose"  behalf of sb...@redhat.com> wrote:
>
>
>
> On Wed, Jan 11, 2017 at 04:00:57PM -0500, Armaan Esfahani wrote:
>
> > Hi, I have setup a Samba server to use FreeIPA as a password
> backend, however whenever I try to use existing users to login I get
> “NT_STATUS_LOGON_FAILURE”.
>
> >
>
> > Looking at the sssd_nss log on my ipa server, I get the following
> error “(Wed Jan 11 15:56:11 2017) [sssd[nss]] [fill_sid] (0x0020): Missing
> SID.”  On all existing accounts, whereas all new accounts function properly
> (after resetting their passwords).
>
> >
>
> >
>
> >
>
> > Anyone have any ideas?
>
>
>
> Maybe the sidgen task was run during ipa-adtrust-install, please see
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterp
> rise_Linux/7/html/Windows_Integration_Guide/creating-
> trusts.html#create-trust-existing-idm
>
> how to run it.
>
>
>
> HTH
>
>
>
> bye,
>
> Sumit
>
>
>
> >
>
>
>
> > --
>
> > 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
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] RFE: Documentation for creating OpenVPN certificates.

[Anthony Joseph Messina]

On Tuesday, January 17, 2017 2:09:08 PM CST Phil Ingram wrote:
> To whom this may concern,
> 
> I use FreeIPA and I would like to create certificates for peer-to-peer and
> remote-access VPNs. In speaking with Fraser Tweedale, we agree that the
> best way forward is to create a secondary CA for insulation; but we may
> also need to create a custom certificate profile, which is non-trivial. As
> an end user of FreeIPA, I would like documentation on how to do this.
> 
> I use pfSense which requires that I upload the CA cert, a server cert and
> its private key. The private key for the CA is optional and only required
> for pfSense to self manage a CRL. On the server side I can also enforce the
> certificate depth; from none, to one through five. The only existing
> references to VPN in the current docs are:
> 
> * http://www.freeipa.org/page/V4/Sub-CAs#VPN_authentication
> 
> * http://www.freeipa.org/page/User_certificate_use_cases
> 
> 
> Regards,
> 
> Phil

I haven't used a sub-CA yet, but the attached certificate profiles have worked 
well for me using OpenVPN.  -A

-- 
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
F9B6 560E 68EA 037D 8C3D  D1C9 FF31 3BDB D9D8 99B6
auth.instance_id=raCertAuth
classId=caEnrollImpl
desc=This certificate profile is for enrolling OpenVPN client certificates with 
IPA-RA agent authentication.
enable=true
enableBy=ipara
input.i1.class_id=certReqInputImpl
input.i2.class_id=submitterInfoInputImpl
input.list=i1,i2
name=IPA-RA Agent-Authenticated OpenVPN Client Certificate Enrollment
output.list=o1
output.o1.class_id=certOutputImpl
policyset.list=serverCertSet
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.accept=true
policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+
policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default
policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, 
O=EXAMPLE.COM 
policyset.serverCertSet.10.constraint.class_id=noConstraintImpl
policyset.serverCertSet.10.constraint.name=No Constraint
policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl
policyset.serverCertSet.10.default.name=Subject Key Identifier Extension Default
policyset.serverCertSet.10.default.params.critical=false
policyset.serverCertSet.11.constraint.class_id=noConstraintImpl
policyset.serverCertSet.11.constraint.name=No Constraint
policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl
policyset.serverCertSet.11.default.name=User Supplied Extension Default
policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17
policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl
policyset.serverCertSet.2.constraint.name=Validity Constraint
policyset.serverCertSet.2.constraint.params.notAfterCheck=false
policyset.serverCertSet.2.constraint.params.notBeforeCheck=false
policyset.serverCertSet.2.constraint.params.range=740
policyset.serverCertSet.2.default.class_id=validityDefaultImpl
policyset.serverCertSet.2.default.name=Validity Default
policyset.serverCertSet.2.default.params.range=731
policyset.serverCertSet.2.default.params.startTime=0
policyset.serverCertSet.3.constraint.class_id=keyConstraintImpl
policyset.serverCertSet.3.constraint.name=Key Constraint
policyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096
policyset.serverCertSet.3.constraint.params.keyType=RSA
policyset.serverCertSet.3.default.class_id=userKeyDefaultImpl
policyset.serverCertSet.3.default.name=Key Default
policyset.serverCertSet.4.constraint.class_id=noConstraintImpl
policyset.serverCertSet.4.constraint.name=No Constraint
policyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl
policyset.serverCertSet.4.default.name=Authority Key Identifier Default
policyset.serverCertSet.5.constraint.class_id=noConstraintImpl
policyset.serverCertSet.5.constraint.name=No Constraint
policyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl
policyset.serverCertSet.5.default.name=AIA Extension Default
policyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true
policyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName
policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.example.com/ca/ocsp
policyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1
policyset.serverCertSet.5.default.params.authInfoAccessCritical=false
policyset.serverCertSet.5.default.params.authInfoAccessNumADs=1
policyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl
policyset.serverCertSet.6.constraint.name=Key Usage Extension Constraint
policyset.serverCertSet.6.constraint.params.keyUsageCritical=true
policyset.serverCertSet.6.constraint.params.keyUsageCrlSign=false
policyset.serverCertSet.6.constraint.par

Re: [Freeipa-users] Lookups Failing With AD Forwarder (and DNSSEC)

[Jason B. Nance]

>> I have a pair of FreeIPA 4.4.0 servers setup whose forwarders are each set 
>> to an
>> Active Directory domain controller.  When a client attempts to lookup any DNS
>> record other than those to which FreeIPA is authoritative the client reports
>> NXDOMAIN and the FreeIPA server has the following in its logs:
>>
>> (first lookup)
>> Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error 
>> (no
>> valid RRSIG) resolving 'zone/DS/IN': 10.48.8.18#53
>> Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error 
>> (no
>> valid DS) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN': 10.48.8.18#53
>>
>> (subsequent lookups)
>> Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: 
>> validating
>> @0x7f7a40983ea0: sl1mmgpwtdc0001.tkc.gen.zone A: bad cache hit (zone/DS)
>> Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error
>> (broken trust chain) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN':
>> 10.48.8.18#53
>>
>> In my case, ipa.tkc.gen.zone is served by FreeIPA and tkc.gen.zone is served 
>> by
>> AD (as is gen.zone).  10.48.8.18 is an AD domain controller for tkc.gen.zone
>> (and the forwarder the FreeIPA servers are pointed at).
>>
>> I've tried "rndc flush" and "rndc flushname ." on the FreeIPA boxes.  We've
>> tried both NSEC3 and NSEC.
>>
>> Anyone have guidance as to what may be going on?
>>
>> Thanks,
>>
>> j
>>
> 
> you use non-existent TLD domain or TLD domain doesn't have DS record of
> your zone, so this is expected behavior for DNSSEC considered as attack.
> You have to disable DNSSEC validation on all IPA DNS servers in
> /etc/named.conf in first case or fix incorrect/missing DS record in
> second case.
> 
> The 'zone.' is registered TLD, so if you own it you have probably
> missing DS record in path, thus broken trust chain.
> If you don't own the TLD, you shouldn't use it at all.

Hi Martin,

Thank you for the reply, and sorry for the delay in response.  My employer owns 
the "gen.zone" domain.  It is used internally only, and served by an Active 
Directory domain controller.

It appears, though, that our registrar does not support DNSSEC for .zone 
domains even though the .zone TLD in general does support DNSSEC.

:-\

j




-- 
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] RFE: Documentation for creating OpenVPN certificates.

[Jochen Hein]

Phil Ingram  writes:

> I use FreeIPA and I would like to create certificates for peer-to-peer
> and remote-access VPNs.

I tried to replace may manual easy-CA certificates with FreeIPA ones,
but that didn't work out (but my fallback also broke). My "productive"
VPN connection for now is ocserv, but I'd like to get OpenVPN running
again.

> In speaking with Fraser Tweedale, we agree that the best way forward
> is to create a secondary CA for insulation; but we may also need to
> create a custom certificate profile, which is non-trivial. As an end
> user of FreeIPA, I would like documentation on how to do this.

I'm happy to try something and give feedback.  I think I'll have time at
the end of this month to work on OpenVPN again.

Jochen

-- 
The only problem with troubleshooting is that the trouble shoots back.

-- 
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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]

[Ludwig Krispenz]

On 01/18/2017 02:57 PM, Harald Dunkel wrote:

On 01/17/17 11:38, Sumit Bose wrote:

On Tue, Jan 17, 2017 at 10:44:14AM +0100, Harald Dunkel wrote:

It seems something got corrupted in my ipa setup. I found this in the
sssd log file on Wheezy:

(Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): Processing 
source hosts for rule [allow_all]
(Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error on 
[cn=System: Manage Host 
Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de]

Looks like there was a replication conflict, please see
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
how to resolve it.


This is *way* too hot for me.
I think the procedure in the link about renaming is only needed if you 
want to keep both entries with a "normal" dn. But you want to get rid of 
the conflict entries.  Since you have to cleanup each of them 
individually I would suggest to start with one of them.


First get both the conflict entry and the normal entry and compare them:
ldapsearch   -D "cn=directory manager" . -b "cn=System: Manage Host 
Principals,cn=permissions,cn=pbac,dc=example,dc=de" -s base
ldapsearch  -D "cn=directory manager"  . -b "cn=System: Manage Host 
Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de" 
-s base


They should be identical.
Next check if the conflict entry has child entries:
ldapsearch  -D "cn=directory manager"  . -b "cn=System: Manage Host 
Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de" 
dn


If there are no entries below the conflict entry you can remove it:
ldapmodify - D "cn=directory manager" ..
dn: cn=System: Manage Host 
Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de

changetype: delete


How can I try this in a sandbox?

you can try to reproduce this state on two other machines.
and if you have an established backup and restore process do a backup 
before doing the cleanup



Every helpful comment is highly appreciated
Harri



--
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] Kerberos Clock Skew too great

[Rakesh Rajasekharan]

Hi There,

Sorry could not get back on this  earlier,

> Great, glad it's fixed!  Are these VMs?  If not, you may wish to
> (re?)configure automatic syncing.
 yes these are AWS instances. How do  I reconfigure auto syncing . Is there
a documentation I can follow.
Sorry, haven't done this before and not much info on that part


Apart from this , I also have a correlation between the "Clock skew" issue
and an earlier issue that I posted in another thread.
Basically , noticed that whenver I see clock skew errors, I see a lot of
connections in SYNC_RECV state.

this is the list of SYNC_RECV connections

tcp0  0 10.0.8.45:88   10.0.30.49:42695SYN_RECV
tcp0  0 10.0.8.45:88   10.0.15.72:44991SYN_RECV
tcp0  0 10.0.8.45:88   10.0.2.82:53265 SYN_RECV
tcp0  0 10.0.8.45:88   10.0.31.253:57682   SYN_RECV
tcp0  0 10.0.8.45:88   10.0.34.208:53488   SYN_RECV
tcp0  0 10.0.8.45:88   10.0.27.17:47245SYN_RECV
tcp0  0 10.0.8.45:88   10.0.17.53:54504SYN_RECV
tcp0  0 10.0.8.45:88   10.0.24.78:47796SYN_RECV
tcp0  0 10.0.8.45:88   10.0.4.246:33607SYN_RECV
tcp0  0 10.0.8.45:88   10.0.27.91:34190SYN_RECV
tcp0  0 10.0.8.45:88   10.0.27.248:38012   SYN_RECV
tcp0  0 10.0.8.45:88   10.0.15.139:51319   SYN_RECV
tcp0  0 10.0.8.45:88   10.0.15.175:41188   SYN_RECV


Thanks,
Rakesh



On Tue, Jan 10, 2017 at 12:48 AM, Robbie Harwood 
wrote:

> Rakesh Rajasekharan  writes:
>
> > There were about 1500 hosts that were alerting for "clock skew" and the
> > issue went away only after I did a resync using ntpdate on all those
> hosts
>
> Great, glad it's fixed!  Are these VMs?  If not, you may wish to
> (re?)configure automatic syncing.
>
> > Is it possible that so many higher number of minor offsets adds up and
> > causes it. Coz from the individual offset it looks much below the 5min
> limit
>
> Not as such, if I understand you correctly?  This should only be a
> problem between any two machines that need to communicate (including the
> freeipa KDC).
>
> > Or, is there a way to tell whats the offset limit its actually looking
> for.
>
> 5 minutes almost certainly.  The parameter to configure it is
> "clockskew" in the config files, but I don't think IPA touches that.
>
> Hope that helps,
> --Robbie
>
-- 
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] Limit regular user access only to self service portal

[Georgijs Radovs]

Thank you for your help.


On 2017.01.18. 10:21, Alexander Bokovoy wrote:

On ke, 18 tammi 2017, David Kupka wrote:

On 17/01/17 16:23, Georgijs Radovs wrote:

Hello everyone!

Is it possible to configure Sef-service permissions in FreeIPA in a 
way,
so that, when regular users log in, they don't have read access to 
other

FreeIPA sections like "Policy", "Authentication", "IPA Server"...?

My goal is - when user logs in Self-service portal, he sees only his
user account in "Identity" tab, no other tabs like "Policy" or
"Authentication" and can read and write only to his profile.

Basically, I want to limit user to his account only, so he does not see
information about other accounts.




Hello,
by default user without any added roles can see "Users" and "OTP 
Tokens" tabs and is able to read other users and modify only his 
attributes.


You can find permissions that affects reading user attributes in IPA 
Server->Role Based Access Control->Permissions (eg. System: Read User 
Addressbook Attributes) and change "Bind rule type" from all to 
"permission".
But be aware that modifying the permissions may result in SSSD being 
unable to resolve users unless you add those permissions to hosts 
(SSSD always uses host principal in FreeIPA deployment).

Even with that, I'd not recommend tightening permissions so that users
would not be able to see other users. There are always ways to break
through this 'enforcement', even start with the fact that a user could
actually authenticate with the host principal of their desktop system.
Access to the identity information is not arbitrated in POSIX
environment. Any process under any user could ask for other user and
group identities with standard libc API.

Security through obscurity never works well in a longer term.




--


--
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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]

[Lukas Slebodnik]

On (17/01/17 11:38), Sumit Bose wrote:
>On Tue, Jan 17, 2017 at 10:44:14AM +0100, Harald Dunkel wrote:
>> It seems something got corrupted in my ipa setup. I found this in the
>> sssd log file on Wheezy:
>> 
>> (Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): Processing 
>> source hosts for rule [allow_all]
>> (Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error on 
>> [cn=System: Manage Host 
>> Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de]
>
>Looks like there was a replication conflict, please see
>https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
>how to resolve it.
>
>We already have a ticket for SSSD to ignore those object, but
>unfortunately there is currently no patch available for SSSD so you have
>to resolve the replication conflict to get it working again.
>
HBAC replication conflicts are already ignored in sssd.
But debian wheezy (oldstable) has very old version of sssd 1.8.4-2.
I would recommend to use at least 1.11.7-3 from jessie (debian stable)

LS

-- 
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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]

[Harald Dunkel]

On 01/17/17 11:38, Sumit Bose wrote:
> On Tue, Jan 17, 2017 at 10:44:14AM +0100, Harald Dunkel wrote:
>> It seems something got corrupted in my ipa setup. I found this in the
>> sssd log file on Wheezy:
>>
>> (Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): Processing 
>> source hosts for rule [allow_all]
>> (Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error on 
>> [cn=System: Manage Host 
>> Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de]
> 
> Looks like there was a replication conflict, please see
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
> how to resolve it.
> 

This is *way* too hot for me. How can I try this in a sandbox?


Every helpful comment 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]

[Ludwig Krispenz]

On 01/18/2017 08:13 AM, Harald Dunkel wrote:

Hi Ludwig,

On 01/17/17 17:01, Ludwig Krispenz wrote:

On 01/17/2017 04:48 PM, Harald Dunkel wrote:

On 01/17/17 16:12, Harald Dunkel wrote:

On 01/17/17 11:38, Sumit Bose wrote:

On Tue, Jan 17, 2017 at 10:44:14AM +0100, Harald Dunkel wrote:

It seems something got corrupted in my ipa setup. I found this in the
sssd log file on Wheezy:

(Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): Processing 
source hosts for rule [allow_all]
(Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error on 
[cn=System: Manage Host 
Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de]

Looks like there was a replication conflict, please see
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
how to resolve it.


% ldapsearch -D "cn=directory manager" -w secret -b "dc=example,dc=de" 
"nsds5ReplConflict=*" \* nsds5ReplConflict | grep nsds5ReplConflict | wc -l
26


PS:

nsds5ReplConflict: namingConflict 
cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de
nsds5ReplConflict: namingConflict 
cn=domain,cn=topology,cn=ipa,cn=etc,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=locations,cn=etc,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=dns 
administrators,cn=privileges,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=dns 
servers,cn=privileges,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=cas,cn=ca,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=custodia,cn=ipa,cn=etc,dc=example,dc=de
nsds5ReplConflict: namingConflict 
cn=dogtag,cn=custodia,cn=ipa,cn=etc,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=system: add 
ca,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=system: delete 
ca,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=system: modify 
ca,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=system: read 
cas,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=system: modify dns servers 
configuration,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=system: read dns servers 
configuration,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=System: Manage Host 
Principals,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=System: Add IPA 
Locations,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=System: Modify IPA 
Locations,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=System: Read IPA 
Locations,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=System: Remove IPA 
Locations,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=System: Read Locations of IPA 
Servers,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=System: Read Status of Services on IPA 
Servers,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=System: Manage Service 
Principals,cn=permissions,cn=pbac,dc=example,dc=de
nsds5ReplConflict: namingConflict cn=System: Manage User 
Principals,cn=permissions,cn=pbac,dc=example,dc=de

This looks like a problem of ipa-server-install. These entries were created
in the very first seconds.

Conflict entries are created if an entry is added on different servers at the "same 
time", where same time means it is created on instance x before the add of the entry 
on instance y was replicated to x. This can happen if you run things in parallel, eg 
upgrades.


You mean Freeipa has a race condition? I use tools like clusterssh to
install or upgrade several hosts in parallel (n <= 49 due to available
screen and font size). The "same time" is built in.

Of course I understand that Freeipa is a special case, because it is
network application, but it should be able to handle n = 2.
it is handling it (389-ds does), but the way it is handling it has the 
conflict entries as a result.


If you add an entry to an instance it is assigned a unique identifier, 
the nsuniqeuid. The dn of an entry can change by modrdn, but the 
nsuniqueid is not changed. The nsuniqueid is also used in replication to 
identify which is the entry the replicated op has to be applied to.If 
you add entries with the same dn in parallel you have entries with the 
same dn but different nsuniqueids, this cannot be prevented, on instance 
has no control of what happens on another instance.
But if these entries are replicated you have two entries with the same 
dn but different nsuniqueids on the same server. This violates the ldap 
data model and ds needs to handle it. The way we do it is to transform 
one of the entries (always the same on all insta

Re: [Freeipa-users] Limit regular user access only to self service portal

[Alexander Bokovoy]

On ke, 18 tammi 2017, David Kupka wrote:

On 17/01/17 16:23, Georgijs Radovs wrote:

Hello everyone!

Is it possible to configure Sef-service permissions in FreeIPA in a way,
so that, when regular users log in, they don't have read access to other
FreeIPA sections like "Policy", "Authentication", "IPA Server"...?

My goal is - when user logs in Self-service portal, he sees only his
user account in "Identity" tab, no other tabs like "Policy" or
"Authentication" and can read and write only to his profile.

Basically, I want to limit user to his account only, so he does not see
information about other accounts.




Hello,
by default user without any added roles can see "Users" and "OTP 
Tokens" tabs and is able to read other users and modify only his 
attributes.


You can find permissions that affects reading user attributes in IPA 
Server->Role Based Access Control->Permissions (eg. System: Read User 
Addressbook Attributes) and change "Bind rule type" from all to 
"permission".
But be aware that modifying the permissions may result in SSSD being 
unable to resolve users unless you add those permissions to hosts 
(SSSD always uses host principal in FreeIPA deployment).

Even with that, I'd not recommend tightening permissions so that users
would not be able to see other users. There are always ways to break
through this 'enforcement', even start with the fact that a user could
actually authenticate with the host principal of their desktop system.
Access to the identity information is not arbitrated in POSIX
environment. Any process under any user could ask for other user and
group identities with standard libc API.

Security through obscurity never works well in a longer term.

--
/ 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] Limit regular user access only to self service portal

[David Kupka]

On 17/01/17 16:23, Georgijs Radovs wrote:

Hello everyone!

Is it possible to configure Sef-service permissions in FreeIPA in a way,
so that, when regular users log in, they don't have read access to other
FreeIPA sections like "Policy", "Authentication", "IPA Server"...?

My goal is - when user logs in Self-service portal, he sees only his
user account in "Identity" tab, no other tabs like "Policy" or
"Authentication" and can read and write only to his profile.

Basically, I want to limit user to his account only, so he does not see
information about other accounts.




Hello,
by default user without any added roles can see "Users" and "OTP Tokens" 
tabs and is able to read other users and modify only his attributes.


You can find permissions that affects reading user attributes in IPA 
Server->Role Based Access Control->Permissions (eg. System: Read User 
Addressbook Attributes) and change "Bind rule type" from all to 
"permission".
But be aware that modifying the permissions may result in SSSD being 
unable to resolve users unless you add those permissions to hosts (SSSD 
always uses host principal in FreeIPA deployment).


--
David Kupka

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