Re: [Freeipa-users] How to change kerberos key lifetime?

[David Kupka]

On Wed, Feb 15, 2017 at 02:13:04PM -0500, William Muriithi wrote:
> Hello
> 
> We are currently mostly using RHEL 6 on the clients but IPA is on RHEL
> 7.3. I am using Kerberos to authenticate NFS mount and its working
> fine.  However, there is a lot of users who are complaining that its
> causing too much problems.  They are all related to key expiry
> 
> 
> I have looked at how to rectify this and noticed that the only
> solution with RHEL 6 is to increase the time the key is valid.
> However, it hasn't worked, the key lifetime remains a day and maximum
> lifetime of 7 days.
> 
> These are the changes I have made so far:
> 
> Changed the policy on IPA:
> 
> [root@lithium ~]# ipa krbtpolicy-show
>   Max life: 15552000
>   Max renew: 25552000
> [root@lithium ~]#
> 
> 
> Changed kerberos configuration:
> 
> [libdefaults]
>   default_realm = ENG.EXAMPLE.COM
>   dns_lookup_realm = true
>   dns_lookup_kdc = true
>   rdns = false
>   ticket_lifetime = 4320h
>   forwardable = yes
>   udp_preference_limit = 0
> 
> 
> Changed sssd configurations:
> 
> [domain/eng.example.com]
> 
> krb5_renewable_lifetime = 180d
> krb5_renew_interval = 3600
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = eng.example.com
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = platinum.eng.example.com
> chpass_provider = ipa
> ipa_dyndns_update = True
> ipa_server = _srv_, lithium.eng.example.com
> ldap_tls_cacert = /etc/ipa/ca.crt
> autofs_provider = ipa
> ipa_automount_location = default
> [sssd]
> services = nss, sudo, pam, autofs, ssh
> 
> domains = eng.example.com
> [nss]
> homedir_substring = /home
> 
> None have lead to any difference as seem below.  What would I be missing?
> 
> Ticket cache: FILE:/tmp/krb5cc_782_L8aH9N
> Default principal: will...@eng.example.com
> 
> Valid starting ExpiresService principal
> 02/15/17 13:17:11  02/22/17 13:17:11  krbtgt/eng.example@eng.example.com
> renew until 03/01/17 13:17:11
> 
> Regards,
> William
> 
> -- 
> 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

Hello William,
first you're mantioning "key expiry" but if I understand corectly you're
interested in "ticket lifetime". 

As mentioned here [1] the ticket lifetime is the minimum of 4 values:
1) maxlife for the user principal
2) maxlife for the service [principal]
3) max_life in the kdc.conf
4) requested lifetime in the ticket request

You've already done 1) (ipa krbtpolicy) and 4) (ticket_lifetime in
[libdefaults] in /etc/krb5.conf on client).

To increase 2) you need to change maxlife for krbtgt service. There're two ways
this ca be done:
a) modifying krbMaxTicketLife attribute in
krbPrincipalName=krbtgt/example@example.org,cn=EXAMPLE.ORG,cn=kerberos,dc=example,dc=org
b) using kadmin.local:
# kadmin.local
Authenticating as principal admin/ad...@example.org
: modprinc -maxlife 10day krbtgt/EXAMPLE.ORG
Principal "krbtgt/example@example.org" modified.
: exit

To increase 3) you need to change 'max_life' in /var/kerberos/krb5kdc/kdc.conf
and restart krb5kdc service.

But generally I don't think it's a good idea to have such long tickets. Would
it make sense in your use case to deploy SSSD on user systems to handle
Kerberos tickets for them?

[1] http://mailman.mit.edu/pipermail/kerberos/2009-February/014520.html

-- 
David Kupka


signature.asc
Description: PGP 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] DM Password Reset in 4.4.0

[Jason B. Nance]

Hello All,

I have managed to lose the Directory Manager password for my FreeIPA 4.4.0 
instance.  I've found the following documentation:


http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html

And:

http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password

I'm confused as to whether I need to follow the procedure in the second link 
because of the following note on the page:

The following procedure is only applicable to FreeIPA 3.2.1 or older. Since 
FreeIPA 3.2.2 (and ticket #3594), the procedure is automated as a part of 
preparing a replica info file by using ipa-replica-prepare

The wording of that seems to indicate that it is a copy/paste from a different 
doc on how to setup PKI (due to the reference to ipa-replica-prepare).

Could someone shed some light on the proper way to go about resetting the 
Directory Manager password in 4.4.0?

Thanks,

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] IPA and SSSD sudo

[Jakub Hrozek]

On Wed, Feb 15, 2017 at 02:44:18PM +0100, Troels Hansen wrote:
> The same rule works as expected if defined in the local sudoers file.

Then I guess this might be a bug..

> 
> I think the problem is that secure_path in "Options" from IPA isn't taken 
> into account.

options should be treated just as any other attribute, so more or les
transparently.

Could you run an ldbsearch of the database to check how was the sudo
rule stored to the sssd cache?

See:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

-- 
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] How to change kerberos key lifetime?

[William Muriithi]

Hello

We are currently mostly using RHEL 6 on the clients but IPA is on RHEL
7.3. I am using Kerberos to authenticate NFS mount and its working
fine.  However, there is a lot of users who are complaining that its
causing too much problems.  They are all related to key expiry


I have looked at how to rectify this and noticed that the only
solution with RHEL 6 is to increase the time the key is valid.
However, it hasn't worked, the key lifetime remains a day and maximum
lifetime of 7 days.

These are the changes I have made so far:

Changed the policy on IPA:

[root@lithium ~]# ipa krbtpolicy-show
  Max life: 15552000
  Max renew: 25552000
[root@lithium ~]#


Changed kerberos configuration:

[libdefaults]
  default_realm = ENG.EXAMPLE.COM
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 4320h
  forwardable = yes
  udp_preference_limit = 0


Changed sssd configurations:

[domain/eng.example.com]

krb5_renewable_lifetime = 180d
krb5_renew_interval = 3600
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = eng.example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = platinum.eng.example.com
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = _srv_, lithium.eng.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
autofs_provider = ipa
ipa_automount_location = default
[sssd]
services = nss, sudo, pam, autofs, ssh

domains = eng.example.com
[nss]
homedir_substring = /home

None have lead to any difference as seem below.  What would I be missing?

Ticket cache: FILE:/tmp/krb5cc_782_L8aH9N
Default principal: will...@eng.example.com

Valid starting ExpiresService principal
02/15/17 13:17:11  02/22/17 13:17:11  krbtgt/eng.example@eng.example.com
renew until 03/01/17 13:17:11

Regards,
William

-- 
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] ssh pubkeys and and AD

[Nathanaël Blanchet]

Hi,

I successfully set an active trust between my linux IPA domain and AD.
I added a few AD account to id views, and I can sucessfully login to my 
linux machines with plain password.


Now, I added my ssh pub key to these servers and I see two kinds of 
behaviour:


 * I can login with the ssh pubkey on new created account (with id view)
 * But on previous created account, if I first login with a password
   and switch to a pub key authentication, I can't login without password.
 * In opposite, if I remove the key to a user that sucessfully
   authenticated, he still can continue to login without password.

I suppose it must exist a cache system, I tried to see several option in 
sssd.conf as |offline_credentials_expiration, 
||account_cache_expiration, ||entry_cache_timeout, but nothing changes.|


|Thank you for your help.
|

--
Nathanaël Blanchet

Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr

-- 
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] Cannot install 3rd party certificate

[Matt .]

Hi,

Is there any update on this ? I need to install 3 other instances but
I would like to know upfront if it might be a bug.

Thanks,

Matt

2017-02-14 17:59 GMT+01:00 Matt . :
> Hi Florance,
>
> Sure I can, here you go:
>
> Fedora 24
> Freeipa VERSION: 4.4.2, API_VERSION: 2.215
>
> I installed this server as self-signed CA
>
> Cheers,
>
> Matt
>
>
>
>
> 2017-02-14 17:54 GMT+01:00 Florence Blanc-Renaud :
>> On 02/14/2017 05:43 PM, Matt . wrote:
>>>
>>> Hi Florance,
>>>
>>> Thanks for your update, good to see some good into about it. For
>>> Comodo I have install all these:
>>>
>>> AddTrustExternalCARoot.crt
>>> COMODORSAAddTrustCA.crt
>>> COMODORSADomainValidationSecureServerCA.crt
>>>
>>>  Where COMODORSADomainValidationSecureServerCA.crt is not needed as
>>> far as I know but the same issues still exist, the Server-Cert is
>>> removed again on ipa-certupdate and fails.
>>>
>>> I have tried this with setenforce 0
>>>
>> Hi Matt,
>>
>> can you provide more info in order to reproduce the issue?
>> - which OS are you using
>> - IPA version
>> - how did you install ipa server (CA-less or with self-signed CA or with
>> externally-signed CA?)
>>
>> Thanks,
>> Flo.
>>
>>
>>> Cheers,
>>>
>>> Matt
>>>
>>> 2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud :

 On 02/14/2017 02:54 PM, Matt . wrote:
>
>
> Certs are valid, I will check what you mentioned.
>
> I'm also no fan of bundles, more the seperate files but this doesn't
> seem to work always. At least for the CAroot a bundle was required.
>
 Hi Matt,

 if your certificate was provided by an intermediate CA, you need to add
 each
 CA before running ipa-server-certinstall (start from the top-level CA
 with
 ipa-cacert-manage install, then run ipa-certupdate, then the intermediate
 CA
 with ipa-cacert-manage install, then ipa-certupdate etc...)

 There is also a known issue with ipa-certupdate and SELinux in enforcing
 mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024).

 Flo.


> Matt
>
> 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI]
> :
>>
>>
>> Have you validated the cert (and dumped the contents) from the command
>> line using the openssl tools?  I’ve seen the message you are seeing
>> before,
>> for some reason I seem to remember that it has to do with either a
>> missing
>> or an extra - at either the -BEGIN CERTIFICATE or -END
>> CERTIFICATE (an error from copy and pasting and not copying the
>> actual
>> file).
>>
>> I’ve never used certupdate so if what is described above doesn’t help
>> somebody else will have to chime in.
>>
>> Dan
>>
>>> On Feb 14, 2017, at 2:18 AM, Matt .  wrote:
>>>
>>> Hi Dan,
>>>
>>> Ues i have tried that and I get the message that it misses the full
>>> chain for the certificate.
>>>
>>> My issue is more, why is the Server-Cert being removed on a certupdate
>>> ?
>>>
>>> Cheers,
>>>
>>> Matt
>>>
>>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI]
>>> :


 Is the chain in mydomain_com_bundle.crt?  Have you tried it with the
 cert only (disclaimer: I’ve never done this).

 Dan

> On Feb 13, 2017, at 4:08 PM, Matt .  wrote:
>
> Hi Guys,
>
> I'm trying to install a 3rd party certificate using:
>
>
>
> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA
>
> When I run the install command for the certificate itself:
>
> ]# ipa-server-certinstall -w -d mydomain_com.key
> mydomain_com_bundle.crt
> Directory Manager password:
>
> Enter private key unlock password:
>
> list index out of range
> The ipa-server-certinstall command failed.
>
>
> If I do a #ipa-certupdate the Server-Cert is removed from
> /etc/httpd/alias and the install fails because of this.
>
> What can I do to solve this ?
>
> Thanks,
>
> Matt
>
> --
> 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] Delegation + visibility on users/user groups

[Alexander Bokovoy]

On ke, 15 helmi 2017, Michael Ströder wrote:

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.

You seem to assume something that is not really part of FreeIPA design.
FreeIPA has flat DIT, with no OUs or other segregation means. All users
and all groups are at the same level, there is no mechanism to prevent
them from being invisible to each other.

Additionally, it would not give you much of protection against hosts
because each enrolled host can see (read-only) all users and groups. If
host principals would not be able to do so, SSSD would not be able to
retrieve identity information.

Even if user has no control over its own enrolled machine, POSIX
identity retrieval API also has no separation feature. If you are able
to issue getpwnam() or getpwuid() call, you are able to methodically
iterate through all POSIX attributes of all users, even inefficiently.

Note FreeIPA is not alone at this. Active Directory allows all machines
in the domain to query identity information even if you are not able to
see it directly from LDAP. Global Catalog service also gives all users
at least read-only access to whole forest's identity information.

This is why I called a proposed approach to solve this use-case as
security through obscurity. The API is there to readily retrieve most of
the information without really involved effort.

--
/ 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] 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] Bind Journal errors

[Martin Basti]

On 15.02.2017 14:10, Raul Dias wrote:

Hello,

My IPA's named daemon start to show this dyndb journal logs:

   error: malformed transaction: 
dyndb-ldap/ipa/master/17.10.10.in-addr.arpa/raw.jnl last serial 
1484327694 != transaction first serial 1484327693


restarting it did not help.

What should I do?

Thanks
-rsd



Hello, could you provide broader context, are there logged any events 
before this error message?

Do you use dns views?

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

Re: [Freeipa-users] IPA and SSSD sudo

[Troels Hansen]

The same rule works as expected if defined in the local sudoers file.

I think the problem is that secure_path in "Options" from IPA isn't taken into 
account.

As described, if I add the path to the one i local sudoers the sudo command 
from IPA works.


- On Feb 15, 2017, at 2:38 PM, Jakub Hrozek jhro...@redhat.com wrote:

> On Wed, Feb 15, 2017 at 11:04:47AM +0100, Troels Hansen wrote:
>> Hi there
>> 
>> We have a strange problem...
>> 
>> We're trying to override options in sudo rules from IPA, in this case
>> secure_path:
>> 
>> sudo -ll reports:
>> 
>> RunAsUsers: root
>> Options: requiretty, lecture=always, timestamp_timeout=0, !authenticate,
>> secure_path=/bin:/usr/bin:/usr/local/bin
>> Commands:
>> stopinst
>> /usr/local/bin/stopinst
>> /usr/local/bin/startinst
>> /bin/mount /rman
>> /usr/bin/su - root
>> 
>> /usr/local/bin is also in my local path:
>> 
>> $ echo $PATH
>> /usr/local/bin:/usr/bin:/usr/local/sbin..
>> 
>> For easyness, stopinst is currently quite simple:
>> 
>> $ cat /usr/local/bin/stopinst
>> #!/bin/bash
>> echo stopinst
>> echo "Path: $PATH"
>> 
>> I can execute the script a normal user, using full path or just the command:
>> $ stopinst
>> stopinst
>> Path:
>> /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/net.dr.dk/drextrha/.local/bin:/home/net.dr.dk/drextrha/bin
>> 
>> However, trying to execute the script using sudo fails:
>> $ sudo stopinst
>> [sudo] password for drextrha:
>> sudo: stopinst: command not found
>> 
>> Unless using full path:
>> $ sudo /usr/local/bin/stopinst
>> stopinst
>> Path: /bin:/usr/bin:/usr/local/bin
>> 
>> Secure path in sudoers is:
>> # grep secure_path /etc/sudoers
>> Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
>> 
>> If I change the secure_path in local sudoers to include /usr/local/bin:
>> # grep secure_path /etc/sudoers
>> Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
>> 
>> I can execute the command using sudo:
>> 
>> $ sudo stopinst
>> stopinst
>> Path: /bin:/usr/bin:/usr/local/bin
>> 
>> S.. something gets overwritten somewhere that shouldn't???
> 
> We shouldn't rewrite anything on the SSSD side. In general, when it
> comes to delivering SUDO rules, SSSD should more or less just act as a
> proxy.
> 
> Did you try to define a similar rule locally in /etc/sudoers to see if
> the same issue happens with a local rule? That should at least confirm
> or deny that the issue might be in SSSD.
> 
> --
> 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

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere.

-- 
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] IPA and SSSD sudo

[Jakub Hrozek]

On Wed, Feb 15, 2017 at 11:04:47AM +0100, Troels Hansen wrote:
> Hi there 
> 
> We have a strange problem... 
> 
> We're trying to override options in sudo rules from IPA, in this case 
> secure_path: 
> 
> sudo -ll reports: 
> 
> RunAsUsers: root 
> Options: requiretty, lecture=always, timestamp_timeout=0, !authenticate, 
> secure_path=/bin:/usr/bin:/usr/local/bin 
> Commands: 
> stopinst 
> /usr/local/bin/stopinst 
> /usr/local/bin/startinst 
> /bin/mount /rman 
> /usr/bin/su - root 
> 
> /usr/local/bin is also in my local path: 
> 
> $ echo $PATH 
> /usr/local/bin:/usr/bin:/usr/local/sbin.. 
> 
> For easyness, stopinst is currently quite simple: 
> 
> $ cat /usr/local/bin/stopinst 
> #!/bin/bash 
> echo stopinst 
> echo "Path: $PATH" 
> 
> I can execute the script a normal user, using full path or just the command: 
> $ stopinst 
> stopinst 
> Path: 
> /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/net.dr.dk/drextrha/.local/bin:/home/net.dr.dk/drextrha/bin
>  
> 
> However, trying to execute the script using sudo fails: 
> $ sudo stopinst 
> [sudo] password for drextrha: 
> sudo: stopinst: command not found 
> 
> Unless using full path: 
> $ sudo /usr/local/bin/stopinst 
> stopinst 
> Path: /bin:/usr/bin:/usr/local/bin 
> 
> Secure path in sudoers is: 
> # grep secure_path /etc/sudoers 
> Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin 
> 
> If I change the secure_path in local sudoers to include /usr/local/bin: 
> # grep secure_path /etc/sudoers 
> Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin 
> 
> I can execute the command using sudo: 
> 
> $ sudo stopinst 
> stopinst 
> Path: /bin:/usr/bin:/usr/local/bin 
> 
> S.. something gets overwritten somewhere that shouldn't??? 

We shouldn't rewrite anything on the SSSD side. In general, when it
comes to delivering SUDO rules, SSSD should more or less just act as a
proxy.

Did you try to define a similar rule locally in /etc/sudoers to see if
the same issue happens with a local rule? That should at least confirm
or deny that the issue might be in SSSD.

-- 
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] Bind Journal errors

[Raul Dias]

Hello,

My IPA's named daemon start to show this dyndb journal logs:

   error: malformed transaction: 
dyndb-ldap/ipa/master/17.10.10.in-addr.arpa/raw.jnl last serial 
1484327694 != transaction first serial 1484327693


restarting it did not help.

What should I do?

Thanks
-rsd

--
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] Cannot enter $ character in "group name" of "user groups"

[Jens Timmerman]

On 15/02/2017 13:52, Alexander Bokovoy wrote:
> On ke, 15 helmi 2017, Jens Timmerman wrote:
>> Hi Martin,
>>
>>
>> On 15/02/2017 12:27, Martin Basti wrote:
>>>
>>>
>>>
>>> On 15.02.2017 10:57, Dimitris Beletsiotis wrote:
 Hello,

 Despite the documentation that says that we can use $ in "group
 names" the web gui does not allow it, pls see attached.
 Is there some option to enable this?

 Thanks,
 Dimitris Beletsiotis


>>> Hello,
>>>
>>> I checked the code and '$' can be used only as the last character in
>>> group name, so error message is not quite exact
>>>
>>> PATTERN_GROUPUSER_NAME =
>>> '^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?$'
>> Since this is a pattern to be matched, the $ actually means something
>> (it is an end of string anchor) and is not a literal '$' character.
>> see
>> http://www.regular-expressions.info/anchors.html
> The third set of allowed characters at the end includes $. The set
> [a-zA-Z0-9_.$-]? has '?' qualifier which means it is optional. But end
> result is to allow '$' as the last character of a group or user name.
>
> However, '$' is not allowed anywhere else. This makes possible to have
> machine or trusted domain accounts for Active Directory/Samba purposes
> but nothing else with '$' sign in the name.
>
Oops, Indeed, I just noticed, read a bit too fast, sorry for the junk.

-- 
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] Cannot enter $ character in "group name" of "user groups"

[Alexander Bokovoy]

On ke, 15 helmi 2017, Jens Timmerman wrote:

Hi Martin,


On 15/02/2017 12:27, Martin Basti wrote:




On 15.02.2017 10:57, Dimitris Beletsiotis wrote:

Hello,

Despite the documentation that says that we can use $ in "group
names" the web gui does not allow it, pls see attached.
Is there some option to enable this?

Thanks,
Dimitris Beletsiotis



Hello,

I checked the code and '$' can be used only as the last character in
group name, so error message is not quite exact

PATTERN_GROUPUSER_NAME = '^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?$'

Since this is a pattern to be matched, the $ actually means something
(it is an end of string anchor) and is not a literal '$' character.
see
http://www.regular-expressions.info/anchors.html

The third set of allowed characters at the end includes $. The set
[a-zA-Z0-9_.$-]? has '?' qualifier which means it is optional. But end
result is to allow '$' as the last character of a group or user name.

However, '$' is not allowed anywhere else. This makes possible to have
machine or trusted domain accounts for Active Directory/Samba purposes
but nothing else with '$' sign in the name.

--
/ 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] Cannot enter $ character in "group name" of "user groups"

[Jens Timmerman]

Hi Martin,


On 15/02/2017 12:27, Martin Basti wrote:
>
>
>
> On 15.02.2017 10:57, Dimitris Beletsiotis wrote:
>> Hello,
>>
>> Despite the documentation that says that we can use $ in "group
>> names" the web gui does not allow it, pls see attached.
>> Is there some option to enable this?
>>
>> Thanks,
>> Dimitris Beletsiotis
>>
>>
> Hello,
>
> I checked the code and '$' can be used only as the last character in
> group name, so error message is not quite exact
>
> PATTERN_GROUPUSER_NAME = '^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?$'
Since this is a pattern to be matched, the $ actually means something
(it is an end of string anchor) and is not a literal '$' character.
see
http://www.regular-expressions.info/anchors.html

Regards,
Jens Timmerman

>
> Martin^2
>
>

-- 
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] Cannot enter $ character in "group name" of "user groups"

[Martin Babinsky]

On 02/15/2017 10:57 AM, Dimitris Beletsiotis wrote:

Hello,

Despite the documentation that says that we can use $ in "group names"
the web gui does not allow it, pls see attached.
Is there some option to enable this?

Thanks,
Dimitris Beletsiotis




The IdM documentation states that dollar sign at the end of user/group 
name is due to Samba 3.x support[1]. I an yet to find a reason why $ is 
forbidden in all other positions.


[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-users-life-cycle.html#username-format


--
Martin^3 Babinsky

--
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] Cannot login after patching on LXC Container

[Nuno Higgs]

Hello,

I've done a fresh install of a Centos7 container and the problem was seen again.
The lxc build installed the files as described within the enclosed txt file.

For versions:

# yum --showduplicates list ipa-client ipa-client-common ipa-common 
python2-ipalib python2-ipaclient

Installed Packages

ipa-client.x86_64   
   4.4.0-14.el7.centos.4

  @updates
ipa-client-common.noarch
   4.4.0-14.el7.centos.4

  @updates
ipa-common.noarch   
   4.4.0-14.el7.centos.4

  @updates
python2-ipaclient.noarch
   4.4.0-14.el7.centos.4

  @updates
python2-ipalib.noarch   
   4.4.0-14.el7.centos.4

  @updates

Available Packages
ipa-client.x86_64   
   4.4.0-12.el7.centos  

  base
ipa-client.x86_64   
   4.4.0-14.el7.centos  

  updates 
ipa-client.x86_64   
   4.4.0-14.el7.centos.1.1  

  updates 
ipa-client.x86_64   
   4.4.0-14.el7.centos.4

  updates 
ipa-client-common.noarch
   4.4.0-12.el7.centos  

  base
ipa-client-common.noarch
   4.4.0-14.el7.centos  

  updates 
ipa-client-common.noarch
   4.4.0-14.el7.centos.1.1  

  updates 
ipa-client-common.noarch
   4.4.0-14.el7.centos.4

  updates 
ipa-common.noarch   
   4.4.0-12.el7.centos  

  base
ipa-common.noarch   
   4.4.0-14.el7.centos  

  updates 
ipa-common.noarch   
   4.4.0-14.el7.centos.1.1  

  updates 
ipa-common.noarch   
   4.4.0-14.el7.centos.4

  updates 

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

[Gerald Zabos]

Hello Alexander,

> Not seeing other users or objects is no possible with FreeIPA design. It is 
> also security through obscurity and doesn't really contribute anything.

> You should be looking at proper permissions/roles to confine what bob and 
> others could actually do, not see.

> I have practical example in my blog, for hosts, not people: 
> https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/

Thanks for your answers. Your blog was already a good starting point
for me in the past. This article is exactly why i got here with my
question ;-)

--

Regards,

Gerald Zabos



On Wed, Feb 15, 2017 at 11:51 AM, Alexander Bokovoy  wrote:
> On ke, 15 helmi 2017, Gerald Zabos wrote:
>>
>> Hello all,
>>
>> after setting up a productive IPA 4.4 environment with eight nodes (master
>> + replicas) on four different locations everything works well. Good job,
>> guys.
>>
>> I am tinkering around with user management and prepared an example setup:
>>
>> - create one supervisor user (bob)
>> - create four team users on bob's team (bridget, betty, bernard, bill)
>> - create a user group (b-team) with bob, bridget, betty, bernard, bill as
>> active users in that team
>>
>> Now i want to achieve the following:
>>
>> - supervisor (bob) can see his team members (bridget, betty, bernard,
>> bill)
>> -and only his team members- to handle administrative tasks within his team
>> -and only his team- , e.g. reset their password, lock their account,
>> change
>> their information.
>>
>> 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.
>
> You should be looking at proper permissions/roles to confine what bob
> and others could actually do, not see.
>
>
>> Can someone please point me to the right documentation and/or give me
>> hints
>> on how to achieve this?
>
> I have practical example in my blog, for hosts, not people:
> https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/
>
> --
> / 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] Cannot enter $ character in "group name" of "user groups"

[Martin Basti]

On 15.02.2017 10:57, Dimitris Beletsiotis wrote:

Hello,

Despite the documentation that says that we can use $ in "group names" 
the web gui does not allow it, pls see attached.

Is there some option to enable this?

Thanks,
Dimitris Beletsiotis



Hello,

I checked the code and '$' can be used only as the last character in 
group name, so error message is not quite exact


PATTERN_GROUPUSER_NAME = '^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?$'

Martin^2
-- 
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

[Alexander Bokovoy]

On ke, 15 helmi 2017, Gerald Zabos wrote:

Hello all,

after setting up a productive IPA 4.4 environment with eight nodes (master
+ replicas) on four different locations everything works well. Good job,
guys.

I am tinkering around with user management and prepared an example setup:

- create one supervisor user (bob)
- create four team users on bob's team (bridget, betty, bernard, bill)
- create a user group (b-team) with bob, bridget, betty, bernard, bill as
active users in that team

Now i want to achieve the following:

- supervisor (bob) can see his team members (bridget, betty, bernard, bill)
-and only his team members- to handle administrative tasks within his team
-and only his team- , e.g. reset their password, lock their account, change
their information.

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.

You should be looking at proper permissions/roles to confine what bob
and others could actually do, not see.



Can someone please point me to the right documentation and/or give me hints
on how to achieve this?

I have practical example in my blog, for hosts, not people:
https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/

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

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

[Gerald Zabos]

Hello all,

after setting up a productive IPA 4.4 environment with eight nodes (master
+ replicas) on four different locations everything works well. Good job,
guys.

I am tinkering around with user management and prepared an example setup:

- create one supervisor user (bob)
- create four team users on bob's team (bridget, betty, bernard, bill)
- create a user group (b-team) with bob, bridget, betty, bernard, bill as
active users in that team

Now i want to achieve the following:

- supervisor (bob) can see his team members (bridget, betty, bernard, bill)
-and only his team members- to handle administrative tasks within his team
-and only his team- , e.g. reset their password, lock their account, change
their information.

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

Can someone please point me to the right documentation and/or give me hints
on how to achieve this?

Regards,

Gerald
-- 
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 and SSSD sudo

[Troels Hansen]

Hi there 

We have a strange problem... 

We're trying to override options in sudo rules from IPA, in this case 
secure_path: 

sudo -ll reports: 

RunAsUsers: root 
Options: requiretty, lecture=always, timestamp_timeout=0, !authenticate, 
secure_path=/bin:/usr/bin:/usr/local/bin 
Commands: 
stopinst 
/usr/local/bin/stopinst 
/usr/local/bin/startinst 
/bin/mount /rman 
/usr/bin/su - root 

/usr/local/bin is also in my local path: 

$ echo $PATH 
/usr/local/bin:/usr/bin:/usr/local/sbin.. 

For easyness, stopinst is currently quite simple: 

$ cat /usr/local/bin/stopinst 
#!/bin/bash 
echo stopinst 
echo "Path: $PATH" 

I can execute the script a normal user, using full path or just the command: 
$ stopinst 
stopinst 
Path: 
/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/net.dr.dk/drextrha/.local/bin:/home/net.dr.dk/drextrha/bin
 

However, trying to execute the script using sudo fails: 
$ sudo stopinst 
[sudo] password for drextrha: 
sudo: stopinst: command not found 

Unless using full path: 
$ sudo /usr/local/bin/stopinst 
stopinst 
Path: /bin:/usr/bin:/usr/local/bin 

Secure path in sudoers is: 
# grep secure_path /etc/sudoers 
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin 

If I change the secure_path in local sudoers to include /usr/local/bin: 
# grep secure_path /etc/sudoers 
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin 

I can execute the command using sudo: 

$ sudo stopinst 
stopinst 
Path: /bin:/usr/bin:/usr/local/bin 

S.. something gets overwritten somewhere that shouldn't??? 
-- 
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] Cannot enter $ character in "group name" of "user groups"

[Dimitris Beletsiotis]

Hello,

Despite the documentation that says that we can use $ in "group names" 
the web gui does not allow it, pls see attached.

Is there some option to enable this?

Thanks,
Dimitris Beletsiotis
-- 
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] Cannot login after patching on LXC Container

[Lukas Slebodnik]

On (14/02/17 20:06), Nuno Higgs wrote:
>Hello all,
>
>I will reproduce the issue tomorrow morning on a fresh LXC container.
>For the sestatus:
>
># sestatus
>SELinux status: disabled
>
>That isn’t surprising for the host is not se-enabled, or even a RHEL/CentOS.
>The underlining distro supports apparmor profiles.
FYI: It is not about distribution but about kernel.

>The crappy part is before we did this patch update, everything worked
>perfectly, although with SE Disabled.
>
>I will keep you posted on the LXC test
>
It would be good to find out which package/update broke it.

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