Re: [Freeipa-users] User Roles and access in GUI

2013-04-12 Thread Chandan Kumar
Thanks for the response.

The way we can turn off the anonymous bind in 389 Server. using
 "nsslapd-allow-anonymous-access: off".

Is there any way to limit the read access of user to only to the DNS
entries? In that way I can create a user who could/will be able to see/edit
DNS entries only.

Thanks,
Chandan

On Friday, April 12, 2013, Dmitri Pal wrote:

> On 04/12/2013 02:23 AM, Martin Kosek wrote:
> > On 04/12/2013 01:07 AM, Chandan Kumar wrote:
> >> Hello,
> >>
> >> I have a question regarding Uer Roles and Access in GUI. What I have
> found that
> >> irrespective of Role assigned to a user, he gets read only access
> across the
> >> directory.
> >>
> >> For example, I created one user say "dnsadmin" with only Roles related
> to DNS
> >> such as DNS Servers, DNS Administrator. Now that user has read only
> access to
> >> entire directory. Is there any way of controlling it?
> >>
> >>
> >> Thanks,
> >> Chandan
> >>
> > Hello Chandan,
> >
> > If you create a new role, assign "DNS Administrators" privilege to it,
> and
> > assign that role to user dnsadmin, that user will have write access to
> DNS tree
> > and configuration.
> >
> > Beyond that tree, dnsadmin will have read-only access just like all other
> > non-admin users. If you want dnsadmin to have write access also to other
> > entries, you would need to assign more privileges/roles to it.
> >
> > HTH,
> > Martin
> >
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com 
> > https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
> If you are worried about the read access the LDAP data is traditionally
> readable by any authenticated user.
> In the past is was even possible to read the tree as anonymous user
> which is a bad security practice and not recommended.
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> ---
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com 
> https://www.redhat.com/mailman/listinfo/freeipa-users
>


-- 

--
http://about.me/chandank
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris

2013-04-12 Thread Sigbjorn Lie
zfs set sharenfs='sec=krb5' pool/dataset

Natxo Asenjo  wrote:

>hi,
>
>thanks, still not working though:
>
># share -F nfs -o "sec=krb5" -d "homedirs" /export/home
>Could not share: /export/home: invalid security type
>
> # zfs set sharenfs="sec"="krb5" rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
># zfs set "sharenfs"="sec"="krb5" rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
># zfs set sharenfs=sec="krb5" rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
># zfs set sharenfs=sec=krb5 rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
># zfs set "sharenfs=sec=krb5" rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
>
>--
>Groeten,
>natxo
>
>
>On Fri, Apr 12, 2013 at 11:30 PM, Sigbjorn Lie 
>wrote:
>
>> Your syntax seem correct but you need to quote the value.
>>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris

2013-04-12 Thread Natxo Asenjo
hi,

thanks, still not working though:

# share -F nfs -o "sec=krb5" -d "homedirs" /export/home
Could not share: /export/home: invalid security type

 # zfs set sharenfs="sec"="krb5" rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to
invalid options

# zfs set "sharenfs"="sec"="krb5" rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to
invalid options

# zfs set sharenfs=sec="krb5" rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to
invalid options

# zfs set sharenfs=sec=krb5 rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to
invalid options

# zfs set "sharenfs=sec=krb5" rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to
invalid options


--
Groeten,
natxo


On Fri, Apr 12, 2013 at 11:30 PM, Sigbjorn Lie  wrote:

> Your syntax seem correct but you need to quote the value.
>
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris

2013-04-12 Thread Sigbjorn Lie
Your syntax seem correct but you need to quote the value.

Natxo Asenjo  wrote:

>hi,
>
>apparently what I am trying to do is not very usual because I do not
>get
>any answer on the omnios (opensolaris derivative) mailing list.
>
>I have successfully joined a host to the ipa domain, I can log in the
>omnios host as an ipa user, getent works, kerberos works (thanks to
>Johan
>Petersson in this thread:
>https://www.redhat.com/archives/freeipa-users/2013-January/msg00021.html)
>
>But when configuring nfs with krb5(i/p) security I get an error:
>
># zfs set sharenfs=sec=krb5 rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
># share -F nfs -o sec=krb5 -d "homedirs" /export/home/
>Could not share: /export/home: invalid security type
>
>The omnios host has a keytab with both host and nfs principals:
>
># klist -k -e
>
>Keytab name: FILE:/etc/krb5/krb5.keytab
>KVNO Principal
>
>--
>   1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with
>96-bit SHA-1 HMAC)
>   1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with
>96-bit SHA-1 HMAC)
> 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with
>HMAC/sha1)
>   1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5)
>   2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with
>96-bit SHA-1 HMAC)
>   2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with
>96-bit SHA-1 HMAC)
>2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with
>HMAC/sha1)
>  2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5)
>
>I can kinit with both principals:
>
>root@testomnios:~# kinit -k
>root@testomnios:~# klist
>Ticket cache: FILE:/tmp/krb5cc_0
>Default principal: host/testomnios.ipa.asenjo...@ipa.asenjo.nx
>
>Valid startingExpiresService principal
>04/12/13 11:56:07  04/13/13 11:56:07 
>krbtgt/ipa.asenjo...@ipa.asenjo.nx
>renew until 04/19/13 11:56:07
>root@testomnios:~# kinit -k nfs/testomnios.ipa.asenjo.nx
>root@testomnios:~# klist
>Ticket cache: FILE:/tmp/krb5cc_0
>Default principal: nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx
>
>Valid startingExpiresService principal
>04/12/13 11:56:28  04/13/13 11:56:28 
>krbtgt/ipa.asenjo...@ipa.asenjo.nx
>renew until 04/19/13 11:56:28
>
>so the keytab is correct
>
>I have edited /etc/nfssec.conf and removed the comments for the krb5
>lines.
>
>According to all my google-fu it should work, but it does not. Any tips
>greatly appreciated.
>.
>--
>Groeten,
>natxo
>
>
>
>
>___
>Freeipa-users mailing list
>Freeipa-users@redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris

2013-04-12 Thread Dmitri Pal
On 04/12/2013 03:35 PM, Natxo Asenjo wrote:
> hi,
>
> apparently what I am trying to do is not very usual because I do not
> get any answer on the omnios (opensolaris derivative) mailing list.
>
> I have successfully joined a host to the ipa domain, I can log in the
> omnios host as an ipa user, getent works, kerberos works (thanks to
> Johan Petersson in this thread:
> https://www.redhat.com/archives/freeipa-users/2013-January/msg00021.html)
>
> But when configuring nfs with krb5(i/p) security I get an error:

I am completely unaware how zfs works but...
>
> # zfs set sharenfs=sec=krb5 rpool/export/home
> cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
> to invalid options

That looks like a syntax error.
It seems like krb5 is an invalid option. May be something needs to be
restarted after you changed the config file?


>
> # share -F nfs -o sec=krb5 -d "homedirs" /export/home/
> Could not share: /export/home: invalid security type
>
> The omnios host has a keytab with both host and nfs principals:
>
> # klist -k -e
>
> Keytab name: FILE:/etc/krb5/krb5.keytab
> KVNO Principal
> 
> --
>1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with
> 96-bit SHA-1 HMAC)
>1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with
> 96-bit SHA-1 HMAC)
>1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode
> with HMAC/sha1)
>1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5)
>2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode
> with 96-bit SHA-1 HMAC)
>2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode
> with 96-bit SHA-1 HMAC)
>2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode
> with HMAC/sha1)
>2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5)
>
> I can kinit with both principals:
>
> root@testomnios:~# kinit -k
> root@testomnios:~# klist  
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: host/testomnios.ipa.asenjo...@ipa.asenjo.nx
>
> Valid startingExpiresService principal
> 04/12/13 11:56:07  04/13/13 11:56:07  krbtgt/ipa.asenjo...@ipa.asenjo.nx
> renew until 04/19/13 11:56:07
> root@testomnios:~# kinit -k nfs/testomnios.ipa.asenjo.nx
> root@testomnios:~# klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx
>
> Valid startingExpiresService principal
> 04/12/13 11:56:28  04/13/13 11:56:28  krbtgt/ipa.asenjo...@ipa.asenjo.nx
> renew until 04/19/13 11:56:28
>
> so the keytab is correct
>
> I have edited /etc/nfssec.conf and removed the comments for the krb5
> lines.
>
> According to all my google-fu it should work, but it does not. Any
> tips greatly appreciated.
> .
> --
> Groeten,
> natxo
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris

2013-04-12 Thread Natxo Asenjo
hi,

apparently what I am trying to do is not very usual because I do not get
any answer on the omnios (opensolaris derivative) mailing list.

I have successfully joined a host to the ipa domain, I can log in the
omnios host as an ipa user, getent works, kerberos works (thanks to Johan
Petersson in this thread:
https://www.redhat.com/archives/freeipa-users/2013-January/msg00021.html)

But when configuring nfs with krb5(i/p) security I get an error:

# zfs set sharenfs=sec=krb5 rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to
invalid options

# share -F nfs -o sec=krb5 -d "homedirs" /export/home/
Could not share: /export/home: invalid security type

The omnios host has a keytab with both host and nfs principals:

# klist -k -e

Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal

--
   1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with
96-bit SHA-1 HMAC)
   1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with
96-bit SHA-1 HMAC)
   1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with
HMAC/sha1)
   1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5)
   2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with
96-bit SHA-1 HMAC)
   2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with
96-bit SHA-1 HMAC)
   2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with
HMAC/sha1)
   2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5)

I can kinit with both principals:

root@testomnios:~# kinit -k
root@testomnios:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/testomnios.ipa.asenjo...@ipa.asenjo.nx

Valid startingExpiresService principal
04/12/13 11:56:07  04/13/13 11:56:07  krbtgt/ipa.asenjo...@ipa.asenjo.nx
renew until 04/19/13 11:56:07
root@testomnios:~# kinit -k nfs/testomnios.ipa.asenjo.nx
root@testomnios:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx

Valid startingExpiresService principal
04/12/13 11:56:28  04/13/13 11:56:28  krbtgt/ipa.asenjo...@ipa.asenjo.nx
renew until 04/19/13 11:56:28

so the keytab is correct

I have edited /etc/nfssec.conf and removed the comments for the krb5 lines.

According to all my google-fu it should work, but it does not. Any tips
greatly appreciated.
.
--
Groeten,
natxo
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP authentication for 3rd party

2013-04-12 Thread Rich Megginson

On 04/11/2013 11:58 PM, Peter Brown wrote:
On 12 April 2013 15:51, Simon Williams 
> wrote:


I use Atlassian products, but use Crowd to provide single signon.
This means that Crowd is the only application that needs to
authenticate against LDAP. I found that I had to tell Crowd that
the server was 389 DS. I could not get it to work set to OpenLDAP.


I had a look at crowd but it seemed like overkill when I could just 
point everything at FreeIPA.

We are a small shop so the extra queries weren't going to affect much.
I tried telling my Atlaassian apps that freeipa was a 389 ds server 
but it refused to work properly.


Not sure what that means, exactly.  Check the 389 access logs to see 
what operations Atlassian is performing against 389.


Slightly strange considering the ldap modules for all of them are the 
same as the one used in crowd.


Regards

Simon

On 11 Apr 2013 23:36, "Peter Brown" mailto:rendhal...@gmail.com>> wrote:

On 12 April 2013 05:04, John Dennis mailto:jden...@redhat.com>> wrote:

On 04/11/2013 02:47 PM, Bartek Moczulski wrote:

hi,
I've got a problem with using IPA as authentication
source over LDAP.
Generally there are two approaches to LDAP authentication:
1. bind using admin account and read passwords from
user objects (but in
ipa you cannot read passwords through ldap, right?)
2. "bind to authenticate" - service tries to log in to
ldap with user's
credentials. If login is successful authentication is
also succesful -
this approach does not work because you cannot login
to IPA ldap using
bare username, you need a full LDAP DN.


Most applications I know of that do "bind as user" to
authenticate also permit you to specify a format string
into which the user name is inserted (i.e. the format
string is the dn, e.g.
"uid=%u,cn=users,cn=accounts,dc=example,dc=com") -or- they
do a search to discover the dn. If you application does
not support either approach it's broken IMHO.


I have used this method for Confluence, Jira, Stash, Icinga
and Foreman.
I will be adding more applications in the future as well.
If the application doesn't support Kerberos it's the next best
thing in my opinion.
I have also use it to get email lists into dovecot and postfix.

One caveat I found is you need to tell Atlassian applications
that FreeIPA is a plain OpenLDAP server to get it to work.
Apart from that it works "out of the box" as they say.



Reading passwords and/or password hashes is not supported
for security reasons.

Now, I've got a 3rd party application supporting both
mentioned above
appoaches and the question is - how to make it work
with ipa?

thanks in advance,
Bartek.


___
Freeipa-users mailing list
Freeipa-users@redhat.com 
https://www.redhat.com/mailman/listinfo/freeipa-users



-- 
John Dennis mailto:jden...@redhat.com>>


Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com 
https://www.redhat.com/mailman/listinfo/freeipa-users



___
Freeipa-users mailing list
Freeipa-users@redhat.com 
https://www.redhat.com/mailman/listinfo/freeipa-users




___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] User Roles and access in GUI

2013-04-12 Thread Dmitri Pal
On 04/12/2013 02:23 AM, Martin Kosek wrote:
> On 04/12/2013 01:07 AM, Chandan Kumar wrote:
>> Hello,
>>
>> I have a question regarding Uer Roles and Access in GUI. What I have found 
>> that
>> irrespective of Role assigned to a user, he gets read only access across the
>> directory. 
>>
>> For example, I created one user say "dnsadmin" with only Roles related to DNS
>> such as DNS Servers, DNS Administrator. Now that user has read only access to
>> entire directory. Is there any way of controlling it? 
>>
>>
>> Thanks,
>> Chandan
>>
> Hello Chandan,
>
> If you create a new role, assign "DNS Administrators" privilege to it, and
> assign that role to user dnsadmin, that user will have write access to DNS 
> tree
> and configuration.
>
> Beyond that tree, dnsadmin will have read-only access just like all other
> non-admin users. If you want dnsadmin to have write access also to other
> entries, you would need to assign more privileges/roles to it.
>
> HTH,
> Martin
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


If you are worried about the read access the LDAP data is traditionally
readable by any authenticated user.
In the past is was even possible to read the tree as anonymous user
which is a bad security practice and not recommended.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] EXTERNAL: Re: ipa-replica-install errors

2013-04-12 Thread Joseph, Matthew (EXP)
Hey,

I tried recreating the replica information and doing the ipa-replica-install 
and it's still failing at trying to start the replication.
I've also tried doing a force sync and it comes up with that generation ID 
error.

Matt

-Original Message-
From: Jatin Nansi [mailto:jna...@redhat.com] 
Sent: Thursday, April 11, 2013 10:18 PM
To: Joseph, Matthew (EXP)
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] EXTERNAL: Re: ipa-replica-install errors

On 04/11/2013 08:55 PM, Joseph, Matthew (EXP) wrote:
> Hey,
>
> Sorry didn't read your full message and realize you wanted all of the 
> information for it.
>
> The Signature Algorithm is PKCS #1 SHA-256 with RSA Encryption.
OK, then it was just the CA certificate that was missing, the MD5 hash 
information that I provided does not apply.

About:

>  "Replica Data has a different generation ID than the local data"

Its probably best if you reinitialize the replica. If the ipa-replica-install 
script never completed, you could try creating a new replica information file 
from the existing IPA server and redo the whole replica installation.



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users