Re: [Freeipa-users] Jenkins integration?

[Michael Ströder]

Maciej Drobniuch wrote:
> I see now what you mean.
> 
> The SSHA decoding is handled on the client side by using acegi not on the 
> ldap server
> side... 

No, Jenkins sends a bind request with the user's bind-DN and clear-text 
password.
Password check is done server-side.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] support for rfc2307AIX schema in IPA server

[Michael Ströder]

Iulian Roman wrote:
> Michael Ströder <mich...@stroeder.com> wrote:
>> Being in your position I'd first compile a list of functional and security 
>> requirements and ask then whether these requirements can be implemented with
>> FreeIPA. I'm curious to learn whether "some other security related 
>> attributes" are
>> still needed after all.
> 
> It is not a matter if they increase the security or not or if they are really 
> needed,
> but a matter of complying to some security standards agreed between two 
> parties . It
> would be easy to keep them in the same format than to change the security 
> standard ,
> tooling and processes behind (bureaucracy , overhead and complexity of the 
> enterprise
> environment makes me try to avoid that as much as possible , especially when 
> there are
> many people and departments involved , with their own mindset and playing 
> different
> politics).

Sounds like the usual IAM business - nothing special.

Still my recommendation would to go the route to list the requirements and 
implement them
in with methods native in the IAM system of your choice (here FreeIPA). This 
might look
harder in the beginning but pays off pretty soon.

Ciao, Michael.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] support for rfc2307AIX schema in IPA server

[Michael Ströder]

Iulian Roman wrote:
> On Wed, Feb 22, 2017 at 6:03 PM, Michael Ströder <mich...@stroeder.com
> <mailto:mich...@stroeder.com>> wrote:
> 
> Iulian Roman wrote:
> > On Tue, Feb 21, 2017 at 4:31 PM, Rob Crittenden <rcrit...@redhat.com 
> <mailto:rcrit...@redhat.com>
> > <mailto:rcrit...@redhat.com <mailto:rcrit...@redhat.com>>> wrote:
> >
> > Iulian Roman wrote:
> > > Does anybody know if the rfc2307aix schema is supported in IPA 
> server
> >
> > No, it isn't supported (it's the first I've ever heard of it). 
> Looking
> > at the schema I doubt it is something that would ever be fully 
> supported.
> >
> > is there any possibility to extend the existing schema with additional
> > attributes/object
> 
> Do you really use this specific AIX schema?
> If yes, which attributes for which purpose?
> 
> I do need the aixAuxAccount and aixAuxGroup object classes . they implement 
> some
> password restrictions needed for security/compliance

Password policy is something best enforced centrally in the authentication 
server and
password management system. So IMHO this serves as perfect example for 
proprietary
attributes you won't need.

How is authentication done? SSH keys, Kerberos, LDAP simple bind?

> +  some other security related attributes.
> Personally i do not consider them a must - they are rather some nice to have 
> features  -
> but i have to migrate an environment which does use them. And i would like as 
> well to
> make the migration as transparent as possible (therefore without "missing 
> features").

Is the existing environment also an LDAP server with this particular AIX schema?
Or are you trying to follow a migration path to LDAP suggested by IBM docs?

Being in your position I'd first compile a list of functional and security 
requirements
and ask then whether these requirements can be implemented with FreeIPA. I'm 
curious to
learn whether "some other security related attributes" are still needed after 
all.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] support for rfc2307AIX schema in IPA server

[Michael Ströder]

Iulian Roman wrote:
> On Tue, Feb 21, 2017 at 4:31 PM, Rob Crittenden  > wrote:
> 
> Iulian Roman wrote:
> > Hello,
> >
> > Does anybody know if the rfc2307aix schema is supported in IPA server (i
> > use red hat IDM version) ? If yes, is there any documentation available
> > ? Was it tested ?
> 
> No, it isn't supported (it's the first I've ever heard of it). Looking
> at the schema I doubt it is something that would ever be fully supported.
> 
> is there any possibility to extend the existing schema with additional 
> attributes/object

Do you really use this specific AIX schema?
If yes, which attributes for which purpose?

Last time I've checked this schema when integrating AIX clients my conclusion 
was that
this schema is rather useless and proprietary bloat.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Delegation + visibility on users/user groups

[Michael Ströder]

On 2017-02-15 11:51, Alexander Bokovoy wrote:

On ke, 15 helmi 2017, Gerald Zabos wrote:

Use case: external customer gets limited access and MUST NOT see our
internal users and/or other external customers.


Not seeing other users or objects is no possible with FreeIPA design. 
It

is also security through obscurity and doesn't really contribute
anything.


IMHO such a use-case is a valid security requirement for preventing
social engineering threats.

Anyway customer accounts are critical regarding _confidentiality_:

1. Customers must not see internal users and their contact data
   for not being able to circumvent controlled support processes.

2. Customers must not see other customers (competitors) because this
   could cause business trouble.

IMHO dealing with customer accounts is very tricky because a normal
user management is optimizied for collaboration and not for
multi-tenant confidentiality.

Ciao, Michael.

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

[Michael Ströder]

Alexander Bokovoy wrote:
> On la, 11 helmi 2017, Michael Ströder wrote:
>> Alexander Bokovoy wrote:
>>> On la, 11 helmi 2017, Harald Dunkel wrote:
>>>> On 02/11/17 11:57, Alexander Bokovoy wrote:
>>>>> On la, 11 helmi 2017, Michael Ströder wrote:
>>>>>>
>>>>>> (Personally I'd avoid going through PAM.)
>>>>> Any specific reason for not using pam_sss? Remember, with SSSD involved
>>>>> you get also authentication for trusted users from Active Directory
>>>>> realms. You don't get that with generic LDAP way. Also, you'd be more
>>>>> efficient in terms of utilising LDAP connections.
>>>>>
>>>>
>>>> I would prefer if the users are not allowed to login into a
>>>> shell on the Jenkins server. Surely this restriction can be
>>>> implemented with pam as well.
>>>
>>> Yes, you can use HBAC rules to prevent them from access to the host.
>>
>> But this introduces a hard dependency on host system administration which I 
>> personally
>> always try to avoid.
>>
>> As said: Your mileage may vary.
>
> So we are talking about FreeIPA and a system enrolled to FreeIPA. This
> system is already managed in FreeIPA.

Please don't get me wrong. Of course I assume that the original poster wants to 
integrate
Jenkins with FreeIPA and make use of users and their group membership already 
maintained
therein.

Let's further assume that the service (here Jenkins) might be operated by 
another team
than the system - not so unusual case at my customers' sites - relying on 
defining HBAC
rules for the system's sssd might not be feasible.

> Your mileage may vary, indeed, but I'd rather re-use what is available
> to you than implement a parallel infrastructure, including reliability
> aspects.

Of course we both agree on the benefits of using what's already available.

> Anyway, I think we are distancing away from the original topic.

Especially since we both can only make rough assumptions about requirements and
operational constraints of the original poster.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Jenkins integration?

[Michael Ströder]

Alexander Bokovoy wrote:
> On la, 11 helmi 2017, Harald Dunkel wrote:
>> On 02/11/17 11:57, Alexander Bokovoy wrote:
>>> On la, 11 helmi 2017, Michael Ströder wrote:
>>>>
>>>> (Personally I'd avoid going through PAM.)
>>> Any specific reason for not using pam_sss? Remember, with SSSD involved
>>> you get also authentication for trusted users from Active Directory
>>> realms. You don't get that with generic LDAP way. Also, you'd be more
>>> efficient in terms of utilising LDAP connections.
>>>
>>
>> I would prefer if the users are not allowed to login into a
>> shell on the Jenkins server. Surely this restriction can be
>> implemented with pam as well.
>
> Yes, you can use HBAC rules to prevent them from access to the host.

But this introduces a hard dependency on host system administration which I 
personally
always try to avoid.

As said: Your mileage may vary.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Jenkins integration?

[Michael Ströder]

Alexander Bokovoy wrote:
> On la, 11 helmi 2017, Michael Ströder wrote:
>> Harald Dunkel wrote:
>>> On 02/10/17 15:07, Tomasz Torcz wrote:
>>>> On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote:
>>>>> did anybody succeed in using Freeipa for Jenkins' LDAP module?
>>>>> I can't make it work :-(.
>>>>
>>>>   I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP.
>>>> I have Jenkins set to PAM authentication, which in turn goes thru SSSD.
>>>> It works fine, groups are resolved correctly, too.
>>>
>>> Thats plan B. Its good to know that this works, but I
>>> don't give up that easy.
>>
>> Jenkins' LDAP integration is pretty good and flexible. I made it work with 
>> various
>> LDAP servers in customer projects. I did not have do that with FreeIPA yet 
>> but I'd
>> be very surprised if it doesn't work.
>>
>> (Personally I'd avoid going through PAM.)
>
> Any specific reason for not using pam_sss?

At the end it's a matter of personal taste.

In my deployments PAM logins have most times nothing to do with the services 
running on a
host which might even use a completely different LDAP service.

> Remember, with SSSD involved you get also authentication for trusted users 
> from Active
> Directory realms. You don't get that with generic LDAP way.

This might be a use-case for which to prefer going through pam_sss.
As usual your mileage may vary. But we both know next to nothing about the 
original
posters infrastructure.

> Also, you'd be more efficient in terms of utilising LDAP connections.

Hmm, IMHO this depends very much on the client software used.
Modern Java software has decent LDAP connection pooling.

Ciao, Michael. (not a Java fan though)




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Jenkins integration?

[Michael Ströder]

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

Jenkins' LDAP integration is pretty good and flexible. I made it work with 
various LDAP
servers in customer projects. I did not have do that with FreeIPA yet but I'd 
be very
surprised if it doesn't work.

(Personally I'd avoid going through PAM.)

Being in your position I'd try to analyze 389-DS' logs to see whether Jenkins 
contacts
your LDAP server and which queries it sends. Most times it's a trivial config 
item missing.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Identification with openLDAP and authorization with FreeIPA

[Michael Ströder]

Alexander Bokovoy wrote:
> On ti, 31 tammi 2017, Rich Megginson wrote:
>> On 01/31/2017 04:46 PM, Michaël Van de Borne wrote:
>>> That was the feared, but somehow expected, answer.
>>>
>>> Any entry point/documentation about how to start such a script?
>>
>> Do FreeIPA and OpenLDAP still support the syncrepl protocol?
>
> a standard syncrepl provider/consumer pair expects to have the very same
> LDAP schema on both sides. This is not the case with OpenLDAP and
> FreeIPA.

Yes.

Another option would be to implement a custom syncrepl client which is of 
course a lot of
work to get it right.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Michael Ströder]

Fil Di Noto wrote:
> In my imagination, I see IPA for whatever reason comes accross a cert
> it signed in the past and decides it needs to compare the SAN to the
> directory. Then it sees the SAN doesn't have an associated principal
> in the directory. Who does IPA trust? (the directory obviously). IPA
> says, "is this SAN in the directory? No. Did I sign the cert? Yes.
> Should I trust the cert? Yes because I signed it."

Speaking purely from the PKI perspective without detailed knowledge about 
FreeIPA:

If the IPA directory is the only assured source of truth then the CA must revoke
the cert because its knowledge about the assertion made in the cert (this public
key belongs to this entity) cannot be verified anymore.

Note that the assertion made in a cert has to be valid for the *complete*
validity period of the cert, not only at the time of cert issuance.

=> If in doubt then revoke.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] cn=deleted users,cn=accounts

[Michael Ströder]

Michael Ströder wrote:
> I wonder which action in the FreeIPA Web UI (4.2.0) moves an active user to
> this container:
> 
> cn=deleted users,cn=accounts,cn=provisioning,dc=example,dc=com
> 
> Selecting [Delete] as action really deletes the LDAP entry.

Ah, found it myself:
It makes a difference choosing action [Delete] when displaying a single user
entry or from the user overview table. The latter asks whether to preserve the
entry or not.

Is this UI inconsistency fixed in a later release?

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] cn=deleted users,cn=accounts

[Michael Ströder]

HI!

I wonder which action in the FreeIPA Web UI (4.2.0) moves an active user to this
container:

cn=deleted users,cn=accounts,cn=provisioning,dc=example,dc=com

Selecting [Delete] as action really deletes the LDAP entry.

Likely I missed something.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] container for custom objects

[Michael Ströder]

HI!

I'd like to add some custom entries (custom STRUCTURAL object class) to FreeIPA
tree in 389-DS. But I'd like to make sure that there won't be any issues when
upgrading the system later on.

So where to add a container for those custom objects?
At top-level domain entry?

BTW: Is there documentation describing the DIT in detail?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] [SSSD-users] heads-up: new code to fetch sudo rules from an IPA server coming to Fedora and RHEL-6

[Michael Ströder]

Jakub Hrozek wrote:
> the sssd's code that fetches sudo rules from the IPA server got an
> overhaul recently. The search would no longer be performed against the
> compat tree, but against IPA's native LDAP tree. This would have the
> advantage that environments that don't use the slapi-nis' compat tree
> for another reason (like old or non-Linux clients) would no longer
> require slapi-nis to be running at all.

Frankly I don't understand this text. Especially I don't know what the terms
"compat tree" and "IPA's native LDAP tree" really mean.

Does this only affect the IPA provider?

Ciao, Michael.

--
Michael Ströder
E-Mail: mich...@stroeder.com
http://www.stroeder.com




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] [SSSD-users] Announcing SSSD 1.13 Alpha

[Michael Ströder]

HI!

I'd be glad if this RFE could make it into 1.13.x:

https://fedorahosted.org/sssd/ticket/2411

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project