[Freeipa-users] IPA sporadic behavior

[John Williams]

I've got some sporadic behavior on my IPA instance and I'm hoping someone can 
help me resolve the issue.  The problem is that many times my clients cannot 
authenticate to the respective hosts.  First, my environment.  Some details:
ipa2 - centos 6.3 -  ipa server 3.0.0ipa3 - centos 7.1 - ipa server 4.1.0
We had a FreeIPA server host ipa1 that died some time ago.  I do not have any 
details on that host.
Again, the problem is that clients cannot authenticate very frequently.  
Here are some examples of the problems I am having:  I client can login to the 
console of a CentOS 6.7 host, but cannot SSH into it.  One user can login to a 
host, but another user cannot.
Some diagnostics information:
Services running on IPA servers:
[root@ipa2 ~]# ps -ef | grep krbroot      6007  5936  0 19:21 pts/5    00:00:00 
grep krbroot     22339     1  0 Feb06 ?        00:00:00 /usr/sbin/krb5kdc -r 
AAA -P /var/run/krb5kdc.pid -w 2root     22344 22339  0 Feb06 ?        00:42:56 
/usr/sbin/krb5kdc -r AAA -P /var/run/krb5kdc.pid -w 2root     22345 22339  0 
Feb06 ?        00:42:50 /usr/sbin/krb5kdc -r AAA -P /var/run/krb5kdc.pid -w 2
[root@ipa3 ~]# ps -ef | grep  krbroot      2513     1  0  2015 ?        
00:00:00 /usr/sbin/krb5kdc -P /var/run/krb5kdc.pid -w 2root      2514  2513  0  
2015 ?        00:01:20 /usr/sbin/krb5kdc -P /var/run/krb5kdc.pid -w 2root      
2515  2513  0  2015 ?        00:01:18 /usr/sbin/krb5kdc -P /var/run/krb5kdc.pid 
-w 2root      5702  5609  0 19:20 pts/1    00:00:00 grep --color=auto krb
slapd is running on both servers:
[root@ipa3 ~]# ps -ef | grep slapddirsrv    2464     1  0  2015 ?        
09:39:37 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-IDEF -i 
/var/run/dirsrv/slapd-IDEF.pid -w /var/run/dirsrv/slapd-IDEF.startpidroot      
5707  5609  0 19:25 pts/1    00:00:00 grep --color=auto slapd[root@ipa3 ~]# 

[root@ipa2 ~]# ps -ef | grep slapdroot      6024  5936  0 19:26 pts/5    
00:00:00 grep slapddirsrv   22137     1  3 Feb06 ?        1-20:48:55 
/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-AAA -i /var/run/dirsrv/slapd-AAA .pid 
-w /var/run/dirsrv/slapd-AAA .startpidpkisrv   22209     1  0 Feb06 ?        
00:44:54 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i 
/var/run/dirsrv/slapd-PKI-IPA.pid -w 
/var/run/dirsrv/slapd-PKI-IPA.startpid[root@ipa2 ~]# 
System time is synchronized across all hosts.
For DNS, I have the following entries:
[root@sharedone ~]# dig ipa.BBB.AAA +short192.168.120.253[root@sharedone ~]# 
dig ipa2.BBB.AAA +short192.168.120.253[root@sharedone ~]# dig ipa3.BBB.AAA 
+short192.168.120.139[root@sharedone ~]# 
Now the ipa.AAA.AAA server does not exist anymore because it died.  But if I 
remove that DNS entrey everything stops working and no one can authenticate, 
versus the sporadic issues we are having.
If you need more detials or specific information, please let me know.  I'm at a 
loss as to what causes this behavior.
Thanks,
JT-- 
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] Announcing FreeIPA 4.3.1

[Petr Vobornik]

The FreeIPA team would like to announce FreeIPA v4.3.1 bug fixing release!

It can be downloaded from http://www.freeipa.org/page/Downloads. The 
builds are available for Fedora 24 and rawhide. Builds for Fedora 23 are 
available in the official COPR 
repository. 
Experimental builds for CentOS 7 will be available in the official 
FreeIPA CentOS7 COPR 
repository 
shortly after Easter Holidays.


This announcement with links to Trac tickets is available on 
http://www.freeipa.org/page/Releases/4.3.1 .


Fedora 24 update: 
https://bodhi.fedoraproject.org/updates/freeipa-4.3.1-1.fc24


== Highlights in 4.3.1 ==
=== Enhancements ===
* FreeIPA Apache instance has an update mod_nss cipher suite to only 
allow secure ciphers #5589
* [[Directory Server]] is configured with "default" cipher suite instead 
of "+all" #5684
* topology graph user experience was improved. Graph is enlarged to fill 
all available space. It can be moved and zoomed so that it handles 
bigger topologies better. #5502, #5649, #5647
* MS-PAC extension was made optional for users #2579, currently without 
UI #5752
* added option to disable preauth for service principal names. 
Configurable via ipaconfigstring value "KDC:Disable Default Preauth for 
SPNs" in server config.  #3860
* improved behavior of DNA plugin in complex FreeIPA environments where 
replicas are not all interconnected so that directory server is able to 
lookup ranges on other servers once a range is exhausted #4026
* 3des and rc4 enctypes are no longer used on new installations of 
FreeIPA server #4740
* `ipa-replica-manage clean-dangling-ruv` subcommand was added to help 
with cases with dandling RUVs, especially the ones related to CA suffix 
#5411
* deprecated keytab_set extended operation was removed from ipasam 
module #5495
* an option was added to Web UI to allow to specify GID number in user 
adder dialog
* improved warning message on uninstallation of replica notifying that 
admin might be removing the last CA, KRA or DNSSec master #5544
* FreeIPA python packages were made independent on architecture(noarch) 
#5596
* AD users are now shown as members of IPA groups when external group is 
added to IPA group #4403


=== Bug fixes ===
* fixed bug where `ipa-cacert-manage install` failed on intermediate CA 
certs #5612
* fixed bug where ipa-server-install didn't stop on error and 
subsequently reported incorrect root cause #2539
* fixed bug where ipa-ca-install hang on creating a temporary CA admin 
during replica promotion #5412

* fixed issue with vault-archive command sometimes not working #5538
* fixed regression in Web UI where required indicator '*' was missing on 
Global Password Policy page, priority field #5553
* fixed regression in reverse zone creation/handling on domain level 0 
in ipa-replica-prepare by adding --auto-reverse and --allow-zone-overlap 
options #5563
* fixed bug where DNS zone overlap check caused failure of 
ipa-dns-install #5564
* fixed upgrade bug which prevents installation of replicas from masters 
updated to 4.3.0 #5575

* fixed rare bug in connection handling which can cause a crash of KDC #5577
* fixed regression in updating DNS entries in `ipa-csreplica-manage del` 
#5583

* fixed not displaying suffixes in IPA servers table in Web UI #5609
* fixed deadlock in directory server between slapi-nis/memberof when a 
topology segment was added/removed #5637
* fixed issue where ipa-adtrust-install sometimes created incorrect SRV 
records #5663


== Upgrading ==
Upgrade instructions are available on upgrade 
page.


== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users 
mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or 
#freeipa channel on Freenode.


== Detailed Changelog since 4.3.0 ==
=== Abhijeet Kasurde (1) ===
* Fixed login error message box in LoginScreen page

=== Alexander Bokovoy (1) ===
* slapi-nis: update configuration to allow external members of IPA groups

=== Christian Heimes (3) ===
* Require Dogtag 10.2.6-13 to fix KRA uninstall
* Modernize mod_nss's cipher suites
* Move user/group constants for PKI and DS into ipaplatform

=== David Kupka (19) ===
* installer: Propagate option values from components instead of copying 
them.

* installer: Fix logic of reading option values from cache.
* ipa-dns-install: Do not check for zone overlap when DNS installed.
* ipa-replica-prepare: Add '--auto-reverse' and '--allow-zone-overlap' 
options

* installer: Change reverse zones question to better reflect reality.
* Fix: Use unattended parameter instead of options.unattended
* CI: Add '2-connected' topology generator.
* CI: Add simple replication test in 2-connected topology.
* CI: Add test for 2-connected topology generator.
* CI: Fix pep8 errors in 2-connected topology generator
* CI: add empty topology test for

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Christophe TREFOIS]

Hi,

Are you not missing “sudo” in [sssd] and did you restard the services on the 
machine? We found quite a significant cache, which sometimes lead to asking 
passwords.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html


You might even have to delete /var/lib/sss/db/ contents and restart sssd.



Best,

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ash Alam
Sent: jeudi 24 mars 2016 19:50
To: Jakub Hrozek 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

Based on (How to troubleshoot Sudo)

- Maybe i miss spoke when i said it fails completely. Rather it keeps asking 
for the users password which it does not accept.
- I do not have sudo in sssd.conf
- I do not have sudoers: sss defined in nsswitch.conf
- Per Fedora/Freeipa doc (Defining Sudo), its not immediately clear if these 
needs to be defined
- If this is the case then adding them might resolve my issues.
- for the special sudo rule(s). is there any way to track it via the gui? I am 
trying to keep track of all the configs so its not a blackhole for the next 
person.

- This is what it looks like on the web gui
[Inline image 1]


- This is what a clients sssd.conf looks like
[domain/x]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = pp
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = xx
chpass_provider = ipa
ipa_server = _srv_, x
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, pam, ssh
config_file_version = 2

domains = X
[nss]
homedir_substring = /home

[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]

On Thu, Mar 24, 2016 at 1:01 PM, Jakub Hrozek 
mailto:jhro...@redhat.com>> wrote:

> On 24 Mar 2016, at 17:21, Ash Alam 
> mailto:aa...@paperlesspost.com>> wrote:
>
> Hello
>
> I am looking for some guidance on how to properly do sudo with Freeipa. I 
> have read up on what i need to do but i cant seem to get to work correctly. 
> Now with sudoers.d i can accomplish this fairly quickly.
>
> Example:
>
> %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
>
> What i have configured in Freeipa Sudo Rules:
>
> Sudo Option: !authenticate
> Who: dev (group)
> Access this host: testing (group)
> Run Commands: set of commands that are defined.
>
> Now when i apply this, it still does not work as it asks for a password for 
> the user and then fails. I am hoping to allow a group to only run certain 
> commands without requiring password.
>

You should first find out why sudo fails completely. We have this guide that 
should help you:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

About asking for passwords -- defining a special sudo rule called 'defaults' 
and then adding '!authenticate' should help:
 Add a special Sudo rule for default Sudo server configuration:
   ipa sudorule-add defaults

 Set a default Sudo option:
   ipa sudorule-add-option defaults --sudooption '!authenticate'

-- 
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] Lock screen when Smart Card is removed.

[Michael Rainey (Contractor)]

Hi Sumit,

Your test packages and configuration changes are working very well. I 
See no issues with the two machines on which the fixes were applied.  
The two systems are running Scientific LInux 7.2 and Centos 7.2.  I will 
continue to perform more tests to see if there are any issues.


I do have another question to ask you in the meantime.  The question was 
asked, "How long would it take for these changes to make there way into 
the current repos?"  Do you think it will take few weeks, or will we 
need to wait for the next point release?  We are just trying to 
determine how to proceed in rolling out the packages.


Thanks again,

*Michael Rainey*

On 03/24/2016 05:09 AM, Sumit Bose wrote:

On Wed, Mar 23, 2016 at 12:25:50PM -0500, Michael Rainey (Contractor) wrote:

Hi Sumit,

I've trying to download the rpm via the Koji client and have been unable to
locate package.  Are there any extra steps I need to complete before I can
find the package, such as, create an account in Fedora Build System.
Performing a general search for SSSD only returns a list of packages from
Fedora Projects and nothing from the EL repo.

The link I sent is the meta link for the different supported platforms
(x86_64, pcc64 and pcc64le). If you select the link for x86_64 you
should be able to see download links for the x86_64 packages.

Nevertheless I created a new build
http://koji.fedoraproject.org/koji/taskinfo?taskID=13446490 to fix some
issue with the package version number in the previous build. The x86_64
packages can be found at
http://koji.fedoraproject.org/koji/taskinfo?taskID=13446491 . To make
the download easy you can try the following command:

curl http://koji.fedoraproject.org/koji/taskinfo?taskID=13446491 | grep -o 
'"https://.*.rpm";' | xargs -n 1 curl -L -O

HTH

bye,
Sumit


Thanks,

*Michael Rainey*
NRL 7320
Computer Support Group
Building 1009, Room C156
Stennis Space Center, MS 39529
On 03/22/2016 07:25 AM, Sumit Bose wrote:

On Fri, Mar 18, 2016 at 10:53:08AM -0500, Michael Rainey (Contractor) wrote:

Hi Sumit,

It has been a week and I am following up with you on the lock screen issue.
Have you had any progress?  If so, I am hoping implementing the fix will be
quick and easy.

Thank you for your patience. Please find a test build for RHEL/CentOS
7.2 at https://koji.fedoraproject.org/koji/taskinfo?taskID=13412048 .

Besides the updated version of SSSD you should replace
/etc/pam.d/smartcard-auth with

 /etc/pam.d/smartcard-auth =
authrequired  pam_env.so
authsufficientpam_sss.so allow_missing_name
authrequired  pam_deny.so

account required  pam_unix.so
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required  pam_permit.so


session optional  pam_keyinit.so revoke
session required  pam_limits.so
-session optional  pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet 
use_uid
session required  pam_unix.so
session optional  pam_sss.so
===

and /etc/dconf/db/distro.d/10-authconfig

= /etc/dconf/db/distro.d/10-authconfig =
[org/gnome/login-screen]
enable-fingerprint-authentication=false

[org/gnome/settings-daemon/peripherals/smartcard]
removal-action='lock-screen'
===

and /etc/dconf/db/distro.d/locks/10-authconfig-locks

== /etc/dconf/db/distro.d/locks/10-authconfig-locks ===
/org/gnome/login-screen/enable-fingerprint-authentication
/org/gnome/settings-daemon/peripherals/smartcard
===

and call 'dconf update' to get the new setting loaded. Finally it might
be a good idea to restart gdm to make sure the new setting and PAM
configuration is really active although I would expect that gdm is able
to pick up the changes at run-time.

Any feedback, good or bad, is welcome.

bye,
Sumit


Thanks,

*Michael Rainey*

On 03/11/2016 02:32 AM, Sumit Bose wrote:

On Thu, Mar 10, 2016 at 01:36:15PM -0600, Michael Rainey (Contractor) wrote:

Greetings,

I have been adding systems to my new domain and utilizing the smart card
login feature.  To date the smart card login feature is working very well.
However, my group has been trying to implement locking the screen when the
smart card is removed, but have not been successful at making it work.  Does
anyone have any suggestions as to what it would take to enable locking the
screen when the smart card is removed.

This requires a better integration with gdm which is currently WIP
(https://fedorahosted.org/sssd/ticket/2941). If you don't mind please
ping me in about a week about this again, then I might have done some
more testing.

bye,
Sumit


Thank you in advance.
--
*Michael Rainey*
--
Manage your subscription for the Freeipa-users mailing list:

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Ash Alam]

I should clarify. I was just following the fedora/ipa docs. My Ipa servers
are Centos 7.2 and Ipa 4.2. Clients are Centos 6.6 and 3.0.0

$ rpm -q sssd ipa-client
sssd-1.11.6-30.el6_6.3.x86_64
ipa-client-3.0.0-42.el6.centos.x86_64

On Thu, Mar 24, 2016 at 3:04 PM, Rob Crittenden  wrote:

> Ash Alam wrote:
>
>> Based on (How to troubleshoot Sudo)
>>
>> - Maybe i miss spoke when i said it fails completely. Rather it keeps
>> asking for the users password which it does not accept.
>> - I do not have sudo in sssd.conf
>> - I do not have sudoers: sss defined in nsswitch.conf
>> - Per Fedora/Freeipa doc (Defining Sudo), its not immediately clear if
>> these needs to be defined
>> - If this is the case then adding them might resolve my issues.
>> - for the special sudo rule(s). is there any way to track it via the
>> gui? I am trying to keep track of all the configs so its not a blackhole
>> for the next person.
>>
>
> It would help to know the release of Fedora you're using, the rpm version
> of ipa-client and sssd.
>
> If you are using Fedora freeipa docs they are extremely old, at best F-18.
> Use the RHEL docs.
>
> rob
>
>
>> - This is what it looks like on the web gui
>> Inline image 1
>>
>>
>> - This is what a clients sssd.conf looks like
>> [domain/x]
>>
>> cache_credentials = True
>> krb5_store_password_if_offline = True
>> ipa_domain = pp
>> id_provider = ipa
>> auth_provider = ipa
>> access_provider = ipa
>> ipa_hostname = xx
>> chpass_provider = ipa
>> ipa_server = _srv_, x
>> ldap_tls_cacert = /etc/ipa/ca.crt
>> [sssd]
>> services = nss, pam, ssh
>> config_file_version = 2
>>
>> domains = X
>> [nss]
>> homedir_substring = /home
>>
>> [pam]
>> [sudo]
>> [autofs]
>> [ssh]
>> [pac]
>> [ifp]
>>
>> On Thu, Mar 24, 2016 at 1:01 PM, Jakub Hrozek > > wrote:
>>
>>
>> > On 24 Mar 2016, at 17:21, Ash Alam > > wrote:
>> >
>> > Hello
>> >
>> > I am looking for some guidance on how to properly do sudo with
>> Freeipa. I have read up on what i need to do but i cant seem to get to work
>> correctly. Now with sudoers.d i can accomplish this fairly quickly.
>> >
>> > Example:
>> >
>> > %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
>> >
>> > What i have configured in Freeipa Sudo Rules:
>> >
>> > Sudo Option: !authenticate
>> > Who: dev (group)
>> > Access this host: testing (group)
>> > Run Commands: set of commands that are defined.
>> >
>> > Now when i apply this, it still does not work as it asks for a
>> password for the user and then fails. I am hoping to allow a group to only
>> run certain commands without requiring password.
>> >
>>
>> You should first find out why sudo fails completely. We have this
>> guide that should help you:
>> https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
>>
>> About asking for passwords -- defining a special sudo rule called
>> 'defaults' and then adding '!authenticate' should help:
>>   Add a special Sudo rule for default Sudo server configuration:
>> ipa sudorule-add defaults
>>
>>   Set a default Sudo option:
>> ipa sudorule-add-option defaults --sudooption '!authenticate'
>>
>>
>>
>>
>>
>
-- 
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 command to batch create users.

[Rob Crittenden]

Natxo Asenjo wrote:


hi,

On Thu, Mar 24, 2016 at 8:14 PM, Armstrong, Jeffrey
mailto:jeffrey.armstr...@gasoc.com>> wrote:

Hello,

__ __

I would like to find out if I can create a large number of users in
IPA at one time.  If so, what is the command to do that.


you can use ipa user-add command in a bash loop, or read the user names
from a file, feeding that file to ipa user-add.


There is also a batch command which is used by the UI to send multiple 
commands at once. This saves on some roundtrip time.


Here is some semi-python, grossly simplified

batch = []
for line in 'output_from_etc_passwd':
(login, passwd, uid, gid, gecos, dir, shell) = line.split(':')
batch.append(dict(method='user_add',
  params=([login], dict(gidnumber=int(gid),
uidnumber=int(uid),
gecos=gecos.strip(), homedir=dir, 
shell=shell,
givenname=first, sn=last, 
noprivate=u'true',
addattr='userPassword={crypt}%s' % 
passwd


results = api.Command['batch'](batch)['results']

You probably don't want too many requests at once, say 50 or 100 might 
be nice.


The results will be a list of all the outputs from the various commands.

rob

--
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 command to batch create users.

[Natxo Asenjo]

hi,

On Thu, Mar 24, 2016 at 8:14 PM, Armstrong, Jeffrey <
jeffrey.armstr...@gasoc.com> wrote:

> Hello,
>
>
>
> I would like to find out if I can create a large number of users in IPA at
> one time.  If so, what is the command to do that.
>
>
>

you can use ipa user-add command in a bash loop, or read the user names
from a file, feeding that file to ipa user-add.

-- 
--
Groeten,
natxo
-- 
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 command to batch create users.

[Armstrong, Jeffrey]

Hello,

I would like to find out if I can create a large number of users in IPA at one 
time.  If so, what is the command to do that.

Jeff




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

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Rob Crittenden]

Ash Alam wrote:

Based on (How to troubleshoot Sudo)

- Maybe i miss spoke when i said it fails completely. Rather it keeps
asking for the users password which it does not accept.
- I do not have sudo in sssd.conf
- I do not have sudoers: sss defined in nsswitch.conf
- Per Fedora/Freeipa doc (Defining Sudo), its not immediately clear if
these needs to be defined
- If this is the case then adding them might resolve my issues.
- for the special sudo rule(s). is there any way to track it via the
gui? I am trying to keep track of all the configs so its not a blackhole
for the next person.


It would help to know the release of Fedora you're using, the rpm 
version of ipa-client and sssd.


If you are using Fedora freeipa docs they are extremely old, at best 
F-18. Use the RHEL docs.


rob



- This is what it looks like on the web gui
Inline image 1


- This is what a clients sssd.conf looks like
[domain/x]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = pp
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = xx
chpass_provider = ipa
ipa_server = _srv_, x
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, pam, ssh
config_file_version = 2

domains = X
[nss]
homedir_substring = /home

[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]

On Thu, Mar 24, 2016 at 1:01 PM, Jakub Hrozek mailto:jhro...@redhat.com>> wrote:


> On 24 Mar 2016, at 17:21, Ash Alam mailto:aa...@paperlesspost.com>> wrote:
>
> Hello
>
> I am looking for some guidance on how to properly do sudo with Freeipa. I 
have read up on what i need to do but i cant seem to get to work correctly. Now 
with sudoers.d i can accomplish this fairly quickly.
>
> Example:
>
> %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
>
> What i have configured in Freeipa Sudo Rules:
>
> Sudo Option: !authenticate
> Who: dev (group)
> Access this host: testing (group)
> Run Commands: set of commands that are defined.
>
> Now when i apply this, it still does not work as it asks for a password 
for the user and then fails. I am hoping to allow a group to only run certain 
commands without requiring password.
>

You should first find out why sudo fails completely. We have this
guide that should help you:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

About asking for passwords -- defining a special sudo rule called
'defaults' and then adding '!authenticate' should help:
  Add a special Sudo rule for default Sudo server configuration:
ipa sudorule-add defaults

  Set a default Sudo option:
ipa sudorule-add-option defaults --sudooption '!authenticate'






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

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Ash Alam]

Based on (How to troubleshoot Sudo)

- Maybe i miss spoke when i said it fails completely. Rather it keeps
asking for the users password which it does not accept.
- I do not have sudo in sssd.conf
- I do not have sudoers: sss defined in nsswitch.conf
- Per Fedora/Freeipa doc (Defining Sudo), its not immediately clear if
these needs to be defined
- If this is the case then adding them might resolve my issues.
- for the special sudo rule(s). is there any way to track it via the gui? I
am trying to keep track of all the configs so its not a blackhole for the
next person.

- This is what it looks like on the web gui
[image: Inline image 1]


- This is what a clients sssd.conf looks like
[domain/x]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = pp
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = xx
chpass_provider = ipa
ipa_server = _srv_, x
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, pam, ssh
config_file_version = 2

domains = X
[nss]
homedir_substring = /home

[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]

On Thu, Mar 24, 2016 at 1:01 PM, Jakub Hrozek  wrote:

>
> > On 24 Mar 2016, at 17:21, Ash Alam  wrote:
> >
> > Hello
> >
> > I am looking for some guidance on how to properly do sudo with Freeipa.
> I have read up on what i need to do but i cant seem to get to work
> correctly. Now with sudoers.d i can accomplish this fairly quickly.
> >
> > Example:
> >
> > %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
> >
> > What i have configured in Freeipa Sudo Rules:
> >
> > Sudo Option: !authenticate
> > Who: dev (group)
> > Access this host: testing (group)
> > Run Commands: set of commands that are defined.
> >
> > Now when i apply this, it still does not work as it asks for a password
> for the user and then fails. I am hoping to allow a group to only run
> certain commands without requiring password.
> >
>
> You should first find out why sudo fails completely. We have this guide
> that should help you:
> https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
>
> About asking for passwords -- defining a special sudo rule called
> 'defaults' and then adding '!authenticate' should help:
>  Add a special Sudo rule for default Sudo server configuration:
>ipa sudorule-add defaults
>
>  Set a default Sudo option:
>ipa sudorule-add-option defaults --sudooption '!authenticate'
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Brad Bendy]

What's your config look like in the GUI? Long as you assign the users
to the group and everything it should work. Your sssd.conf file shows
sudo in there as well?

On Thu, Mar 24, 2016 at 9:21 AM, Ash Alam  wrote:
> Hello
>
> I am looking for some guidance on how to properly do sudo with Freeipa. I
> have read up on what i need to do but i cant seem to get to work correctly.
> Now with sudoers.d i can accomplish this fairly quickly.
>
> Example:
>
> %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
>
> What i have configured in Freeipa Sudo Rules:
>
> Sudo Option: !authenticate
> Who: dev (group)
> Access this host: testing (group)
> Run Commands: set of commands that are defined.
>
> Now when i apply this, it still does not work as it asks for a password for
> the user and then fails. I am hoping to allow a group to only run certain
> commands without requiring password.
>
> Thank You
>
> --
> 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] Freeipa Sudo / sudoers.d / nopasswd

[Jakub Hrozek]

> On 24 Mar 2016, at 17:21, Ash Alam  wrote:
> 
> Hello
> 
> I am looking for some guidance on how to properly do sudo with Freeipa. I 
> have read up on what i need to do but i cant seem to get to work correctly. 
> Now with sudoers.d i can accomplish this fairly quickly.
> 
> Example:
> 
> %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
> 
> What i have configured in Freeipa Sudo Rules:
> 
> Sudo Option: !authenticate
> Who: dev (group)
> Access this host: testing (group)
> Run Commands: set of commands that are defined.
> 
> Now when i apply this, it still does not work as it asks for a password for 
> the user and then fails. I am hoping to allow a group to only run certain 
> commands without requiring password.
> 

You should first find out why sudo fails completely. We have this guide that 
should help you:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

About asking for passwords -- defining a special sudo rule called 'defaults' 
and then adding '!authenticate' should help:
 Add a special Sudo rule for default Sudo server configuration:
   ipa sudorule-add defaults

 Set a default Sudo option:
   ipa sudorule-add-option defaults --sudooption '!authenticate'

-- 
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] Freeipa Sudo / sudoers.d / nopasswd

[Ash Alam]

Hello

I am looking for some guidance on how to properly do sudo with Freeipa. I
have read up on what i need to do but i cant seem to get to work correctly.
Now with sudoers.d i can accomplish this fairly quickly.

Example:

%dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client

What i have configured in Freeipa Sudo Rules:

Sudo Option: !authenticate
Who: dev (group)
Access this host: testing (group)
Run Commands: set of commands that are defined.

Now when i apply this, it still does not work as it asks for a password for
the user and then fails. I am hoping to allow a group to only run certain
commands without requiring password.

Thank You
-- 
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] 7.x replica install from 6.x master fails

[Ott, Dennis]

I am trying to migrate from OS 6.x / IPA 3.0 to OS 7.x / IPA 4.x. After working 
through and solving a few issues, my current efforts fail when setting up the 
replica CA.

If I set up a new, pristine master on OS 6.7, I am able to create an OS 7.x 
replica without any problem. However, if I try to create a replica from my two 
year old test lab instance (production will be another matter for the future) 
it fails. The test lab master was created a couple of years ago on OS 6.3 / IPA 
2.x and has been upgraded to the latest versions in the 6.x chain. It is old 
enough to have had all the certificates renewed, but I believe I have worked 
through all the issues related to that.

Below is what I believe are the useful portions of the pertinent logs. I've not 
been able to find anything online that speaks to the errors I am seeing

Thanks for your help.



/var/log/ipareplica-install.log


2016-03-23T21:55:11Z DEBUG Configuring certificate server (pki-tomcatd). 
Estimated time: 3 minutes 30 seconds
2016-03-23T21:55:11Z DEBUG   [1/23]: creating certificate server user
2016-03-23T21:55:11Z DEBUG group pkiuser exists
2016-03-23T21:55:11Z DEBUG user pkiuser exists
2016-03-23T21:55:11Z DEBUG   duration: 0 seconds
2016-03-23T21:55:11Z DEBUG   [2/23]: configuring certificate server instance
2016-03-23T21:55:11Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-03-23T21:55:11Z DEBUG Saving StateFile to 
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-03-23T21:55:11Z DEBUG Contents of pkispawn configuration file 
(/tmp/tmpGQ59ZC):
[CA]
pki_security_domain_name = IPA
pki_enable_proxy = True
pki_restart_configured_instance = False
pki_backup_keys = True
pki_backup_password = 
pki_profiles_in_ldap = True
pki_client_database_dir = /tmp/tmp-g0CKZ3
pki_client_database_password = 
pki_client_database_purge = False
pki_client_pkcs12_password = 
pki_admin_name = admin
pki_admin_uid = admin
pki_admin_email = root@localhost
pki_admin_password = 
pki_admin_nickname = ipa-ca-agent
pki_admin_subject_dn = cn=ipa-ca-agent,O=EXAMPLE.COM
pki_client_admin_cert_p12 = /root/ca-agent.p12
pki_ds_ldap_port = 389
pki_ds_password = 
pki_ds_base_dn = o=ipaca
pki_ds_database = ipaca
pki_subsystem_subject_dn = cn=CA Subsystem,O=EXAMPLE.COM
pki_ocsp_signing_subject_dn = cn=OCSP Subsystem,O=EXAMPLE.COM
pki_ssl_server_subject_dn = cn=pt-idm-vm01.example.com,O=EXAMPLE.COM
pki_audit_signing_subject_dn = cn=CA Audit,O=EXAMPLE.COM
pki_ca_signing_subject_dn = cn=Certificate Authority,O=EXAMPLE.COM
pki_subsystem_nickname = subsystemCert cert-pki-ca
pki_ocsp_signing_nickname = ocspSigningCert cert-pki-ca
pki_ssl_server_nickname = Server-Cert cert-pki-ca
pki_audit_signing_nickname = auditSigningCert cert-pki-ca
pki_ca_signing_nickname = caSigningCert cert-pki-ca
pki_ca_signing_key_algorithm = SHA256withRSA
pki_security_domain_hostname = ptipa1.example.com
pki_security_domain_https_port = 443
pki_security_domain_user = admin
pki_security_domain_password = 
pki_clone = True
pki_clone_pkcs12_path = /tmp/ca.p12
pki_clone_pkcs12_password = 
pki_clone_replication_security = TLS
pki_clone_replication_master_port = 7389
pki_clone_replication_clone_port = 389
pki_clone_replicate_schema = False
pki_clone_uri = https://ptipa1.example.com:443


2016-03-23T21:55:11Z DEBUG Starting external process
2016-03-23T21:55:11Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f' 
'/tmp/tmpGQ59ZC'
2016-03-23T21:56:51Z DEBUG Process finished, return code=1
2016-03-23T21:56:51Z DEBUG stdout=Log file: 
/var/log/pki/pki-ca-spawn.20160323175511.log
Loading deployment configuration from /tmp/tmpGQ59ZC.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into 
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.

Installation failed.
2016-03-23T21:56:51Z DEBUG 
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: 
InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
certificate verification is strongly advised. See: 
https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
pkispawn: WARNING  ... unable to validate security domain user/password 
through REST interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration Servlet: 500 
Server Error: Internal Server Error
pkispawn: ERROR... ParseError: not well-formed (invalid token): 
line 1, column 0: 
{"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error
 while updating security domain: java.io.IOException: 2"}

2016-03-23T21:56:51Z CRITICAL Failed to configure CA instance: Command 
''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpGQ59ZC'' returned non-zero exit 
status 1
2016-03-23T21:56:51Z CRITICAL See the installation logs and the following 
files/directories for more information:
2016-03-23T21:56:51Z CRITICAL   /var/log/pki-ca-install.log
2016-03-23T21:56:51

Re: [Freeipa-users] Lock screen when Smart Card is removed.

[Sumit Bose]

On Wed, Mar 23, 2016 at 12:25:50PM -0500, Michael Rainey (Contractor) wrote:
> Hi Sumit,
> 
> I've trying to download the rpm via the Koji client and have been unable to
> locate package.  Are there any extra steps I need to complete before I can
> find the package, such as, create an account in Fedora Build System.
> Performing a general search for SSSD only returns a list of packages from
> Fedora Projects and nothing from the EL repo.

The link I sent is the meta link for the different supported platforms
(x86_64, pcc64 and pcc64le). If you select the link for x86_64 you
should be able to see download links for the x86_64 packages.

Nevertheless I created a new build
http://koji.fedoraproject.org/koji/taskinfo?taskID=13446490 to fix some
issue with the package version number in the previous build. The x86_64
packages can be found at
http://koji.fedoraproject.org/koji/taskinfo?taskID=13446491 . To make
the download easy you can try the following command:

curl http://koji.fedoraproject.org/koji/taskinfo?taskID=13446491 | grep -o 
'"https://.*.rpm";' | xargs -n 1 curl -L -O

HTH

bye,
Sumit

> 
> Thanks,
> 
> *Michael Rainey*
> NRL 7320
> Computer Support Group
> Building 1009, Room C156
> Stennis Space Center, MS 39529
> On 03/22/2016 07:25 AM, Sumit Bose wrote:
> >On Fri, Mar 18, 2016 at 10:53:08AM -0500, Michael Rainey (Contractor) wrote:
> >>Hi Sumit,
> >>
> >>It has been a week and I am following up with you on the lock screen issue.
> >>Have you had any progress?  If so, I am hoping implementing the fix will be
> >>quick and easy.
> >Thank you for your patience. Please find a test build for RHEL/CentOS
> >7.2 at https://koji.fedoraproject.org/koji/taskinfo?taskID=13412048 .
> >
> >Besides the updated version of SSSD you should replace
> >/etc/pam.d/smartcard-auth with
> >
> > /etc/pam.d/smartcard-auth =
> >authrequired  pam_env.so
> >authsufficientpam_sss.so allow_missing_name
> >authrequired  pam_deny.so
> >
> >account required  pam_unix.so
> >account sufficientpam_localuser.so
> >account sufficientpam_succeed_if.so uid < 1000 quiet
> >account [default=bad success=ok user_unknown=ignore] pam_sss.so
> >account required  pam_permit.so
> >
> >
> >session optional  pam_keyinit.so revoke
> >session required  pam_limits.so
> >-session optional  pam_systemd.so
> >session [success=1 default=ignore] pam_succeed_if.so service in crond 
> >quiet use_uid
> >session required  pam_unix.so
> >session optional  pam_sss.so
> >===
> >
> >and /etc/dconf/db/distro.d/10-authconfig
> >
> >= /etc/dconf/db/distro.d/10-authconfig =
> >[org/gnome/login-screen]
> >enable-fingerprint-authentication=false
> >
> >[org/gnome/settings-daemon/peripherals/smartcard]
> >removal-action='lock-screen'
> >===
> >
> >and /etc/dconf/db/distro.d/locks/10-authconfig-locks
> >
> >== /etc/dconf/db/distro.d/locks/10-authconfig-locks ===
> >/org/gnome/login-screen/enable-fingerprint-authentication
> >/org/gnome/settings-daemon/peripherals/smartcard
> >===
> >
> >and call 'dconf update' to get the new setting loaded. Finally it might
> >be a good idea to restart gdm to make sure the new setting and PAM
> >configuration is really active although I would expect that gdm is able
> >to pick up the changes at run-time.
> >
> >Any feedback, good or bad, is welcome.
> >
> >bye,
> >Sumit
> >
> >>Thanks,
> >>
> >>*Michael Rainey*
> >>
> >>On 03/11/2016 02:32 AM, Sumit Bose wrote:
> >>>On Thu, Mar 10, 2016 at 01:36:15PM -0600, Michael Rainey (Contractor) 
> >>>wrote:
> Greetings,
> 
> I have been adding systems to my new domain and utilizing the smart card
> login feature.  To date the smart card login feature is working very well.
> However, my group has been trying to implement locking the screen when the
> smart card is removed, but have not been successful at making it work.  
> Does
> anyone have any suggestions as to what it would take to enable locking the
> screen when the smart card is removed.
> >>>This requires a better integration with gdm which is currently WIP
> >>>(https://fedorahosted.org/sssd/ticket/2941). If you don't mind please
> >>>ping me in about a week about this again, then I might have done some
> >>>more testing.
> >>>
> >>>bye,
> >>>Sumit
> >>>
> Thank you in advance.
> -- 
> *Michael Rainey*
> -- 
> 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 subscriptio

Re: [Freeipa-users] Can't Search For Users

[Petr Spacek]

On 23.3.2016 17:52, Garrett Hyde wrote:
> I'm currently running ipa-server version 4.2.0, release 15.el7_2.6 on a
> RHEL 7.2 server.
> 
> When a user **not** in the "admins" group tries searching for a user, they
> receive "No entries." In the WebUI, this happens on the "Active users" page
> or when trying to add a user to a group, role, etc. It also happens when a
> user uses the CLI (e.g., `ipa user-find ...`). I've tried adding a user to
> all of the available roles listed under "Role Based Access Control", but
> they still can't search for users.
> 
> Currently, only users in the "admins" group can search for users. Is there
> a permission or privilege I'm missing? How can I grant users the ability to
> search for other users?

I suspect that you are hitting this bug:
https://fedorahosted.org/freeipa/ticket/5168

It is in our queue, stay tuned.

-- 
Petr^2 Spacek

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