Re: [Freeipa-users] LDAP based autofs map redundancy

[William Muriithi]

Hello,

To add to previous mail, I have noticed this:

I had two IPA, hydrogen and lithium.   lithium died and will be resetting
another soon after I find why the setup isn't redundant with one IPA.  But
this line seem to be a lead

Working:
ipa_server = _srv_, hydrogen.eng.example.com

Failing:
ipa_server = _srv_, lithium.eng.example.com

Have read on that format and seem fine from the reading.  To add on that,
DNS records seem to be fine too.


; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.3 <<>> SRV _ldap._
tcp.eng.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;_ldap._tcp.eng.example.com.IN  SRV

;; ANSWER SECTION:
_ldap._tcp.eng.example.com. 86400 INSRV 0 100 389
hydrogen.eng.example.com.
_ldap._tcp.eng.example.com. 86400 INSRV 0 100 389
lithium.eng.example.com.

;; AUTHORITY SECTION:
eng.example.com.86400   IN  NS  hydrogen.eng.example.com.
eng.example.com.86400   IN  NS  lithium.eng.example.com.

;; ADDITIONAL SECTION:
lithium.eng.example.com. 1200 INA   192.168.20.3
hydrogen.eng.example.com. 1200 IN   A   192.168.20.1

;; Query time: 1 msec
;; SERVER: 192.168.20.1#53(192.168.20.1)
;; WHEN: Tue Mar 14 18:32:44 2017
;; MSG SIZE  rcvd: 200


What could I be missing?

Regards,
William


On 5 March 2017 at 14:59, William Muriithi 
wrote:

> Jakub,
>
> >>
> >> It does look though like kerberos is not affected as all systems can
> >> authenticate fine, so looks like its autofs issue alone
> >>
> >> This is the error I am noticing on the logs.
> >>
> >> Mar  2 14:18:29 platinum automount[2887]: key "brad" not found in map
> source(s).
> >> Mar  2 14:19:18 platinum automount[2887]: bind_ldap_simple:
> >> lookup(ldap): Unable to bind to the LDAP server: (default), error
> >> Can't contact LDAP server
> >> Mar  2 14:19:21 platinum automount[2887]: bind_ldap_simple:
> >> lookup(ldap): Unable to bind to the LDAP server: (default), error
> >> Can't contact LDAP server
> >
> > I guess /etc/nsswitch.conf uses ldap for automount and not sssd?
> >
> Actually no.  We are using SSSD
>
> Just checked to confirm and looks like below:
>
> services:   files sss
> netgroup:   files sss
> publickey:  nisplus
> automount: sss files
> aliases:files nisplus
> sudoers: files sss
>
> 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

Re: [Freeipa-users] Mutli site IPA scenario - DNS issue

[Jan Karásek]

Hi,

this is simply because network design and we are probably not able to change 
that at the moment. So IPA clients are restricted to IPA servers in its own 
site and only IPA servers are able to do inter site communication. 

The plan is to add more IPA server into each site so clients will have backup 
servers inside the each site.
Just now I am simply trying to establish first inter site replication to prove 
that design is possible.

Jan 

- Original Message -
From: "Martin Basti" 
To: "Jan Karásek" , "freeipa-users" 

Sent: Tuesday, March 14, 2017 7:26:18 PM
Subject: Re: [Freeipa-users] Mutli site IPA scenario - DNS issue

On 14.03.2017 17:05, Jan Karásek wrote:
> Hi,
> please can you point me to right direction with this issue ?
> Scenario: 
> Site A, Site B, IPA in Site A is already installed with DNS, CA  and i want 
> to create replica to Site B.
> OS: RHEL 7.3, IPA 4.4
>
>
> Site A - 192.168.0.0/24
> IPA_A server interfaces:
> eth0: 192.168.0.10   -- access for clients in Site A
> eth1: 192.168.10.100 -- interface to Site B
> domain: sitea.mylab.test
>
>
> Site B - 192.168.1.0/24
> IPA_B server interfaces:
> eth0: 192.168.1.10   -- access for clients in Site B
> eth1: 192.168.10.200 -- interface to Site A
> domain: siteb.mylab.test
>
>  
> IPA clients can reach only servers in their own site via eth0 - no access to 
> IPA servers in other sites.
> Servers can communicate with each other only via eth1.
> I am having trouble to find out how to set DNS records for this scenario. 
>
> Just now I have IPA_A installed and i want to create replica to IPA_B server.
> DNS for zone sitea.mylab.test:
>
> ipa_aA192.168.0.10
> ...  SRV  ipa_a.sitea.mylab.test
>
> So just now in DNS I have only A record for interface facing Site A. 
>
> Trouble is that server in Site B (ipa_b) is not able to communicate with 
> server in Site A (ipa_a) via 192.168.0.10 address which it gets from DNS, 
> servers can communicate only on eth1 (192.168.10.0/24).
>
>
> So when I point resolv.conf on IPA_B to IPA_A and try to run 
>
> ipa-replica-install --principal admin --admin-password admin_password 
> --setup-dns --setup-ca ...
>
> I can not access IPA_A server because it is resolving to 192.168.0.10.
>
> So is this supported scenario ? What would be solution ? I can probably fix 
> that in /etc/hosts file, but I would like to keep it all in DNS.
>
> Thank you,
>
> Jan
>
Hello,

this is really nonstandard situation for IPA

I suggest to use just one IP address with IPA to makes things less
complicated, can you leave only 192.168.10.{100|200} for ipaservers and
allow the host subnets to communicate with the particular IPA servers?

Why do you want to prevent clients to communicate with the other IPA
server? You will have no backup for clients in case that one replica failed.

If you just want from clients to prefer closer replica you may want to
use IPA location feature
https://www.freeipa.org/page/Howto/IPA_locations and just keep clients
outside of location failing.


If you really need to separate subnets with different IP addresses, you
need DNS views for that and IPA DNS must be configured to respect that.

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

[Freeipa-users] Fedora 25 IPA smart card login

[Michael Rainey (Contractor)]

Greetings,

I have been working on an issue with smart card logins on a Fedora 25 
system.  For a short time smart card logins have been working well, but 
suddenly the login process has suddenly stopped working.  I have 
verified that all appropriate certificates are installed, checked my 
dconf configuration, checked my PAM files, and reviewed the logs.  I 
have noticed a few issues, but changing them to match my SL7 systems did 
not resolve the problem.


My observation has been with my PAM files and authconfig.  I have 
noticed that when an update occurs, authconfig will run changing my PAM 
files.  Has IPA been integrated with authconfig or do I still need to 
keep the options in authconfig largely disabled and manually modify my 
PAM files?


System Information:


Package:
freeipa-client.x86_644.4.3-2.fc25

PAM:
-
smartcard-auth-ac
-
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

-
password-auth-ac
-
authrequired  pam_env.so
auth[default=1 success=ok] pam_localuser.so
auth[success=done ignore=ignore default=die] pam_unix.so nullok 
try_first_pass

authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so forward_pass
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

passwordrequisite pam_pwquality.so try_first_pass 
local_users_only retry=3 authtok_type=
passwordsufficientpam_unix.so sha512 shadow nullok 
try_first_pass use_authtok

passwordsufficientpam_sss.so use_authtok
passwordrequired  pam_deny.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

-
DCONF: org.gnome.login-screen
-
org.gnome.login-screen fallback-logo ''
org.gnome.login-screen disable-user-list false
org.gnome.login-screen allowed-failures 3
org.gnome.login-screen enable-smartcard-authentication true
org.gnome.login-screen banner-message-enable false
org.gnome.login-screen enable-password-authentication true
org.gnome.login-screen disable-restart-buttons false
org.gnome.login-screen logo '/usr/share/pixmaps/fedora-gdm-logo.png'
org.gnome.login-screen enable-fingerprint-authentication true
org.gnome.login-screen banner-message-text ''

--
*Michael Rainey*
Network Representative
Naval Research Latoratory, Code 7320
Building 1009, Room C156
Stennis Space Center, MS 39529

-- 
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 users can't log in to SDDM

[Tyrell Jentink]

Oh, you are quite right... It's even identified in the project scope of the
original proposal to switch from KDM: "Fix the bugs affecting log in: PAM
stack integration and LDAP user lists"  --
https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM

I'm just going to switch back to KDM...   Should solve my problem.

Thank you!

On Tue, Mar 14, 2017 at 12:46 PM, Alexander Bokovoy 
wrote:

> On ti, 14 maalis 2017, Tyrell Jentink wrote:
>
>> I have users in an AD Domain, my FreeIPA server is set up with an
>> interforest trust, and users can log in using SSH or virtual terminals on
>> any system joined to the IPA domain, and I have Samba authenticating
>> against these users on another server... Things are good...
>>
>> Until I try logging in to the Fedora 25 KDE Respin from the desktop
>> manager
>> (SDDM), in which case it goes to a black screen, with an X as a cursor,
>> but
>> nothing else... This is my first attempt at logging a remote user in
>> through the GUI, and KDE/SDDM is the default configuration on Fedora KDE
>> Respin, thus the combination in question... I haven't tried anything else.
>>
>> Some diagnostics I have tried:
>>
>> If I log in to a virtual terminal and run startx, then I get KDE,
>> regardless of the user.
>> If I log in to SDDM/KDE using a local user, then I get KDE.
>> If I log in to SDDM/KDE using an IPA user, I get the black screen...
>>   But, the audit and security logs show that the user successfully
>> authenticated. Dmesg shows the user getting authenticated successfully and
>> user contexts changing successfully.
>>
>>
>> So, I'm left assuming this is a problem with SDDM somewhere, but only with
>> remote users... And my logs aren't giving me any hints.
>>
>> Any ideas? Any logs in particular that I should be looking at?
>>
> "Black screen" with SDDM is a fairly known issue -- you can look at
> https://bugzilla.redhat.com/show_bug.cgi?id=1350107, for example. Or
> https://github.com/sddm/sddm/issues/756, or many other distros. It looks
> like SDDM is crashing internally on many conditions. The bug in Red Hat
> bugzilla has at least three different cases where SDDM crashes.
>
> I'd suggest you to file a bug and attach system logs to it. You can use
> SSSD troubleshooting guide to create SSSD debug logs (domain, pam, nss,
> and selinux sections at least) but also attach logs for sddm and audit.
>
> --
> / Alexander Bokovoy
>



-- 
Tyrell Jentink
tyrell.jentink.net
-- 
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] sudo sometimes doesn't work

[Orion Poplawski]

On 01/30/2017 01:38 AM, Jakub Hrozek wrote:
> On Fri, Jan 27, 2017 at 02:15:16PM -0700, Orion Poplawski wrote:
>> EL7.3
>> Users are in active directory via AD trust with IPA server
>>
>> sudo is configured via files - users in our default "nwra" group can run
>> certain sudo commands, e.g.:
>>
>> Cmnd_Alias WAKEUP = /sbin/ether-wake *
>> %nwra,%visitor,%ivm   ALL=NOPASSWD: WAKEUP
>>
>> However, sometimes when I run sudo /sbin/ether-wake I get prompted for my
>> password.  Other times it works fine.  I've attached some logs from failed
>> attempt.
> 
> So the sudo command is successfull in the end, it 'just' prompts for a
> password?

No, it fails when given the password:

Sorry, user USER is not allowed to execute '/sbin/ether-wake XXX' as root on 
HOST.

Turns out I'm an idiot.  Needed to run ipa-adtrust-install on all of the IPA
servers and make sure things were working on all of them.  Things would break
depending on which ipa server the client sssd was connected to.

-- 
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

-- 
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] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute

[Matt .]

Hi Rob,

I have this solved, I think it was an issue in the foreman-proxy.

The reason why there are two users in the role was to test other
usernames, as you cannot use foreman-proxy for this for an example.

I need to update the Foreman ticket about it.

Thanks for helping out.

Cheers,

Matt

2017-03-14 19:51 GMT+01:00 Rob Crittenden :
> Matt . wrote:
>> Hi Rob,
>>
>> Thanks for the update, the same error happens when I add a new host,
>> so I'm lost, the same for the Foreman devs.
>>
>> What can I check/test further ?
>
> See what 389-ds is logging in its access log.
>
> You may need to enable ACI summary debugging. See the 389-ds FAQ for
> instructions on how.
>
> I find it curious that there are 2 similarly named foreman users in the
> role.
>
> rob
>
>>
>> Thanks,
>>
>> Matt
>>
>> 2017-03-10 21:20 GMT+01:00 Rob Crittenden :
>>> Matt . wrote:
 Hi Rob,

 Thanks, but what do you mean here ? The Foreman has a script which
 should be OK for it:

 https://github.com/theforeman/smart-proxy/blob/develop/sbin/foreman-prepare-realm

 Can you check this maybe ?
>>>
>>> Like I said, it's wrong.
>>>
>>> add grants the ability to add new entries, not updating existing ones.
>>>
>>> The right needs to be "write".
>>>
>>> rob
>>>

 Thanks,

 Matt

 2017-03-10 17:21 GMT+01:00 Rob Crittenden :
> Matt . wrote:
>> I'm trying to add a host using Foreman to the FreeIPA realm but this
>> doesn't work, all things seem to be fine and some other tests from
>> people are working:
>>
>> The issue is reported here: http://projects.theforeman.org/issues/18850
>>
>>
>> My settings are like this:
>>
>>
>> [root@ipa-01 ~]# ipa role-find
>> ---
>> 6 roles matched
>> ---
>>   Role name: helpdesk
>>   Description: Helpdesk
>>
>>   Role name: IT Security Specialist
>>   Description: IT Security Specialist
>>
>>   Role name: IT Specialist
>>   Description: IT Specialist
>>
>>   Role name: Security Architect
>>   Description: Security Architect
>>
>>   Role name: Smart Proxy Host Manager
>>   Description: Smart Proxy management
>>
>>   Role name: User Administrator
>>   Description: Responsible for creating Users and Groups
>> 
>> Number of entries returned 6
>> 
>> [root@ipa-01 ~]# ipa role-show "Smart Proxy Host Manager"
>>   Role name: Smart Proxy Host Manager
>>   Description: Smart Proxy management
>>   Member users: foreman-proxy, foreman-realm-proxy
>>   Privileges: Smart Proxy Host Management
>> [root@ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management"
>>   Privilege name: Smart Proxy Host Management
>>   Description: Smart Proxy Host Management
>>   Permissions: Retrieve Certificates from the CA, System: Add DNS
>> Entries, System: Read DNS Entries, System: Remove DNS Entries, System:
>> Update DNS
>>Entries, System: Manage Host Certificates, System:
>> Manage Host Enrollment Password, System: Manage Host Keytab, System:
>> Modify Hosts,
>>System: Remove Hosts, System: Manage Service Keytab,
>> System: Modify Services, Add Host Enrollment Password
>>   Granting privilege to roles: Smart Proxy Host Manager
>> [root@ipa-01 ~]#
>> [root@ipa-01 ~]# ipa permission-find "Add Host"
>> -
>> 3 permissions matched
>> -
>>   Permission name: Add Host Enrollment Password
>>   Granted rights: add
>>   Effective attributes: userpassword
>>   Bind rule type: permission
>>   Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>>   Type: host
>>   Permission flags: V2, SYSTEM
>>
>>   Permission name: System: Add Hostgroups
>>   Granted rights: add
>>   Bind rule type: permission
>>   Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>>   Type: hostgroup
>>   Permission flags: V2, MANAGED, SYSTEM
>>
>>   Permission name: System: Add Hosts
>>   Granted rights: add
>>   Bind rule type: permission
>>   Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>>   Type: host
>>   Permission flags: V2, MANAGED, SYSTEM
>> 
>> Number of entries returned 3
>> 
>>
>>
>> Can anyone help me out as I'm unsure where this goes wrong.
>>
>
> For 'Add Host Enrollment Password' the granted rights should be write
> not add.
>
> add is for adding entries, not writing attributes.
>
> rob

>>>
>>
>

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to 

Re: [Freeipa-users] IPA users can't log in to SDDM

[Alexander Bokovoy]

On ti, 14 maalis 2017, Tyrell Jentink wrote:

I have users in an AD Domain, my FreeIPA server is set up with an
interforest trust, and users can log in using SSH or virtual terminals on
any system joined to the IPA domain, and I have Samba authenticating
against these users on another server... Things are good...

Until I try logging in to the Fedora 25 KDE Respin from the desktop manager
(SDDM), in which case it goes to a black screen, with an X as a cursor, but
nothing else... This is my first attempt at logging a remote user in
through the GUI, and KDE/SDDM is the default configuration on Fedora KDE
Respin, thus the combination in question... I haven't tried anything else.

Some diagnostics I have tried:

If I log in to a virtual terminal and run startx, then I get KDE,
regardless of the user.
If I log in to SDDM/KDE using a local user, then I get KDE.
If I log in to SDDM/KDE using an IPA user, I get the black screen...
  But, the audit and security logs show that the user successfully
authenticated. Dmesg shows the user getting authenticated successfully and
user contexts changing successfully.


So, I'm left assuming this is a problem with SDDM somewhere, but only with
remote users... And my logs aren't giving me any hints.

Any ideas? Any logs in particular that I should be looking at?

"Black screen" with SDDM is a fairly known issue -- you can look at
https://bugzilla.redhat.com/show_bug.cgi?id=1350107, for example. Or
https://github.com/sddm/sddm/issues/756, or many other distros. It looks
like SDDM is crashing internally on many conditions. The bug in Red Hat
bugzilla has at least three different cases where SDDM crashes.

I'd suggest you to file a bug and attach system logs to it. You can use
SSSD troubleshooting guide to create SSSD debug logs (domain, pam, nss,
and selinux sections at least) but also attach logs for sddm and audit.

--
/ 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] IPA users can't log in to SDDM

[Tyrell Jentink]

I have users in an AD Domain, my FreeIPA server is set up with an
interforest trust, and users can log in using SSH or virtual terminals on
any system joined to the IPA domain, and I have Samba authenticating
against these users on another server... Things are good...

Until I try logging in to the Fedora 25 KDE Respin from the desktop manager
(SDDM), in which case it goes to a black screen, with an X as a cursor, but
nothing else... This is my first attempt at logging a remote user in
through the GUI, and KDE/SDDM is the default configuration on Fedora KDE
Respin, thus the combination in question... I haven't tried anything else.

Some diagnostics I have tried:

If I log in to a virtual terminal and run startx, then I get KDE,
regardless of the user.
If I log in to SDDM/KDE using a local user, then I get KDE.
If I log in to SDDM/KDE using an IPA user, I get the black screen...
   But, the audit and security logs show that the user successfully
authenticated. Dmesg shows the user getting authenticated successfully and
user contexts changing successfully.


So, I'm left assuming this is a problem with SDDM somewhere, but only with
remote users... And my logs aren't giving me any hints.

Any ideas? Any logs in particular that I should be looking at?
-- 
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] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute

[Rob Crittenden]

Matt . wrote:
> Hi Rob,
> 
> Thanks for the update, the same error happens when I add a new host,
> so I'm lost, the same for the Foreman devs.
> 
> What can I check/test further ?

See what 389-ds is logging in its access log.

You may need to enable ACI summary debugging. See the 389-ds FAQ for
instructions on how.

I find it curious that there are 2 similarly named foreman users in the
role.

rob

> 
> Thanks,
> 
> Matt
> 
> 2017-03-10 21:20 GMT+01:00 Rob Crittenden :
>> Matt . wrote:
>>> Hi Rob,
>>>
>>> Thanks, but what do you mean here ? The Foreman has a script which
>>> should be OK for it:
>>>
>>> https://github.com/theforeman/smart-proxy/blob/develop/sbin/foreman-prepare-realm
>>>
>>> Can you check this maybe ?
>>
>> Like I said, it's wrong.
>>
>> add grants the ability to add new entries, not updating existing ones.
>>
>> The right needs to be "write".
>>
>> rob
>>
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>> 2017-03-10 17:21 GMT+01:00 Rob Crittenden :
 Matt . wrote:
> I'm trying to add a host using Foreman to the FreeIPA realm but this
> doesn't work, all things seem to be fine and some other tests from
> people are working:
>
> The issue is reported here: http://projects.theforeman.org/issues/18850
>
>
> My settings are like this:
>
>
> [root@ipa-01 ~]# ipa role-find
> ---
> 6 roles matched
> ---
>   Role name: helpdesk
>   Description: Helpdesk
>
>   Role name: IT Security Specialist
>   Description: IT Security Specialist
>
>   Role name: IT Specialist
>   Description: IT Specialist
>
>   Role name: Security Architect
>   Description: Security Architect
>
>   Role name: Smart Proxy Host Manager
>   Description: Smart Proxy management
>
>   Role name: User Administrator
>   Description: Responsible for creating Users and Groups
> 
> Number of entries returned 6
> 
> [root@ipa-01 ~]# ipa role-show "Smart Proxy Host Manager"
>   Role name: Smart Proxy Host Manager
>   Description: Smart Proxy management
>   Member users: foreman-proxy, foreman-realm-proxy
>   Privileges: Smart Proxy Host Management
> [root@ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management"
>   Privilege name: Smart Proxy Host Management
>   Description: Smart Proxy Host Management
>   Permissions: Retrieve Certificates from the CA, System: Add DNS
> Entries, System: Read DNS Entries, System: Remove DNS Entries, System:
> Update DNS
>Entries, System: Manage Host Certificates, System:
> Manage Host Enrollment Password, System: Manage Host Keytab, System:
> Modify Hosts,
>System: Remove Hosts, System: Manage Service Keytab,
> System: Modify Services, Add Host Enrollment Password
>   Granting privilege to roles: Smart Proxy Host Manager
> [root@ipa-01 ~]#
> [root@ipa-01 ~]# ipa permission-find "Add Host"
> -
> 3 permissions matched
> -
>   Permission name: Add Host Enrollment Password
>   Granted rights: add
>   Effective attributes: userpassword
>   Bind rule type: permission
>   Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>   Type: host
>   Permission flags: V2, SYSTEM
>
>   Permission name: System: Add Hostgroups
>   Granted rights: add
>   Bind rule type: permission
>   Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>   Type: hostgroup
>   Permission flags: V2, MANAGED, SYSTEM
>
>   Permission name: System: Add Hosts
>   Granted rights: add
>   Bind rule type: permission
>   Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>   Type: host
>   Permission flags: V2, MANAGED, SYSTEM
> 
> Number of entries returned 3
> 
>
>
> Can anyone help me out as I'm unsure where this goes wrong.
>

 For 'Add Host Enrollment Password' the granted rights should be write
 not add.

 add is for adding entries, not writing attributes.

 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] Mutli site IPA scenario - DNS issue

[Martin Basti]

On 14.03.2017 17:05, Jan Karásek wrote:
> Hi,
> please can you point me to right direction with this issue ?
> Scenario: 
> Site A, Site B, IPA in Site A is already installed with DNS, CA  and i want 
> to create replica to Site B.
> OS: RHEL 7.3, IPA 4.4
>
>
> Site A - 192.168.0.0/24
> IPA_A server interfaces:
> eth0: 192.168.0.10   -- access for clients in Site A
> eth1: 192.168.10.100 -- interface to Site B
> domain: sitea.mylab.test
>
>
> Site B - 192.168.1.0/24
> IPA_B server interfaces:
> eth0: 192.168.1.10   -- access for clients in Site B
> eth1: 192.168.10.200 -- interface to Site A
> domain: siteb.mylab.test
>
>  
> IPA clients can reach only servers in their own site via eth0 - no access to 
> IPA servers in other sites.
> Servers can communicate with each other only via eth1.
> I am having trouble to find out how to set DNS records for this scenario. 
>
> Just now I have IPA_A installed and i want to create replica to IPA_B server.
> DNS for zone sitea.mylab.test:
>
> ipa_aA192.168.0.10
> ...  SRV  ipa_a.sitea.mylab.test
>
> So just now in DNS I have only A record for interface facing Site A. 
>
> Trouble is that server in Site B (ipa_b) is not able to communicate with 
> server in Site A (ipa_a) via 192.168.0.10 address which it gets from DNS, 
> servers can communicate only on eth1 (192.168.10.0/24).
>
>
> So when I point resolv.conf on IPA_B to IPA_A and try to run 
>
> ipa-replica-install --principal admin --admin-password admin_password 
> --setup-dns --setup-ca ...
>
> I can not access IPA_A server because it is resolving to 192.168.0.10.
>
> So is this supported scenario ? What would be solution ? I can probably fix 
> that in /etc/hosts file, but I would like to keep it all in DNS.
>
> Thank you,
>
> Jan
>
Hello,

this is really nonstandard situation for IPA

I suggest to use just one IP address with IPA to makes things less
complicated, can you leave only 192.168.10.{100|200} for ipaservers and
allow the host subnets to communicate with the particular IPA servers?

Why do you want to prevent clients to communicate with the other IPA
server? You will have no backup for clients in case that one replica failed.

If you just want from clients to prefer closer replica you may want to
use IPA location feature
https://www.freeipa.org/page/Howto/IPA_locations and just keep clients
outside of location failing.


If you really need to separate subnets with different IP addresses, you
need DNS views for that and IPA DNS must be configured to respect that.

Martin



signature.asc
Description: OpenPGP digital 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] DB locks and Clean RUV

[Ian Harding]

I just updated my FreeIPA server and now the LDAP instance crashes daily
at 9:15 PM.

I have a lot of these in my logs :

Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.781100512
-0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 9): Replica is not
cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389))
Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.781560066
-0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 9): Replicas have
not been cleaned yet, retrying in 14400 seconds
Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.837043110
-0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 16): Replica is not
cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389))
Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.837354975
-0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 16): Replicas have
not been cleaned yet, retrying in 14400 seconds
Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.214216609
-0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 7): Replica is not
cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389))
Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.214609007
-0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 7): Replicas have
not been cleaned yet, retrying in 14400 seconds
Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.286618494
-0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 14): Replica is not
cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389))
Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.287040274
-0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 14): Replicas have
not been cleaned yet, retrying in 14400 seconds


But there are apparently not any tasks running:

[root@freeipa-sea log]# ipa-replica-manage list-clean-ruv
Directory Manager password:

No CLEANALLRUV tasks running

No abort CLEANALLRUV tasks running


The crash happens after:

Mar 13 21:18:13 freeipa-sea ns-slapd: [13/Mar/2017:21:18:13.702716206
-0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out
of db locks getting the
 next entry.  Reduce the batch value and restart.
Mar 13 21:18:15 freeipa-sea ns-slapd: [13/Mar/2017:21:18:15.303117842
-0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out
of db locks getting the
 next entry.  Reduce the batch value and restart.
Mar 13 21:18:16 freeipa-sea ns-slapd: [13/Mar/2017:21:18:16.628504719
-0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out
of db locks getting the
 next entry.  Reduce the batch value and restart.
Mar 13 21:18:17 freeipa-sea ns-slapd: [13/Mar/2017:21:18:17.954354140
-0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out
of db locks getting the
 next entry.  Reduce the batch value and restart.
Mar 13 21:18:19 freeipa-sea ns-slapd: [13/Mar/2017:21:18:19.284145453
-0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out
of db locks getting the
 next entry.  Reduce the batch value and restart.


Is there any way to get rid of the cleanallruv tasks that the system
thinks are not running?

Thanks!

- Ian
-- 
Ian Harding
IT Director
Brown Paper Tickets
1-800-838-3006 ext 7186
http://www.brownpapertickets.com

-- 
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] Mutli site IPA scenario - DNS issue

[Jan Karásek]

Hi,
please can you point me to right direction with this issue ?
Scenario: 
Site A, Site B, IPA in Site A is already installed with DNS, CA  and i want to 
create replica to Site B.
OS: RHEL 7.3, IPA 4.4


Site A - 192.168.0.0/24
IPA_A server interfaces:
eth0: 192.168.0.10   -- access for clients in Site A
eth1: 192.168.10.100 -- interface to Site B
domain: sitea.mylab.test


Site B - 192.168.1.0/24
IPA_B server interfaces:
eth0: 192.168.1.10   -- access for clients in Site B
eth1: 192.168.10.200 -- interface to Site A
domain: siteb.mylab.test

 
IPA clients can reach only servers in their own site via eth0 - no access to 
IPA servers in other sites.
Servers can communicate with each other only via eth1.
I am having trouble to find out how to set DNS records for this scenario. 

Just now I have IPA_A installed and i want to create replica to IPA_B server.
DNS for zone sitea.mylab.test:

ipa_aA192.168.0.10
...  SRV  ipa_a.sitea.mylab.test

So just now in DNS I have only A record for interface facing Site A. 

Trouble is that server in Site B (ipa_b) is not able to communicate with server 
in Site A (ipa_a) via 192.168.0.10 address which it gets from DNS, servers can 
communicate only on eth1 (192.168.10.0/24).


So when I point resolv.conf on IPA_B to IPA_A and try to run 

ipa-replica-install --principal admin --admin-password admin_password 
--setup-dns --setup-ca ...

I can not access IPA_A server because it is resolving to 192.168.0.10.

So is this supported scenario ? What would be solution ? I can probably fix 
that in /etc/hosts file, but I would like to keep it all in DNS.

Thank you,

Jan

-- 
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] Issue upgrading freeipa to ipa-server-4.4.0-14.el7.centos.4.x86_64

[Robert Söderlund]

Hi!
I was a bit eager to fix this so I installed a new ipa-aerver, executed 
ipa migrate-ds and configured the replication afterwards.

Sorry not to be able to troubleshoot this further.

//Robban

On 2017-03-14 16:25, Petr Vobornik wrote:

On 03/08/2017 06:06 PM, free...@netnerdz.se wrote:

Hi all!

I'm trying to upgrade my ipa-server to the version in subject and
hitting some bug that seems similar to
https://bugzilla.redhat.com/show_bug.cgi?id=1404910


It is unlikely that it is this bug because the version of IPA with it
was never released. BUt the error indeed looks similar.



The yum upgrade process took a bit longer than expected so i ctrl+c


This is never a good idea.



it
and executed the command ipa-server-upgrade

The error message from ipa-server-upgrade is:
8<---
IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run
command ipa-server-upgrade manually.
Unexpected error - see /var/log/ipaupgrade.log for details:
OSError: [Errno 2] No such file or directory:
'/etc/pki/pki-tomcat/dogtag.keytab'
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for
more information
[root@o-ipa01-r ~]#
8<---


The lines that indicate an error in the /var/log/ipaupgrade.log file 
is:

8<---
2017-03-07T23:05:38Z DEBUG stdout=Authenticating as principal
root/ad...@netnerdz.se with password.

2017-03-07T23:05:38Z DEBUG stderr=WARNING: no policy specified for
dogtag/o-ipa01-r.ovirt.netnerdz...@netnerdz.se; defaulting to no 
policy

add_principal: Principal or policy already exists while creating
"dogtag/o-ipa01-r.ovirt.netnerdz...@netnerdz.se".

2017-03-07T23:05:38Z INFO Retrieving keytab
2017-03-07T23:05:38Z DEBUG Starting external process
2017-03-07T23:05:38Z DEBUG args=kadmin.local -q ktadd -k
/etc/pki/pki-tomcat/dogtag.keytab
dogtag/o-ipa01-r.ovirt.netnerdz...@netnerdz.se -x
ipa-setup-override-restrictions
2017-03-07T23:05:48Z DEBUG Process finished, return code=0
2017-03-07T23:05:48Z DEBUG stdout=Authenticating as principal
root/ad...@netnerdz.se with password.

2017-03-07T23:05:48Z DEBUG stderr=kadmin.local: Server error while
changing dogtag/o-ipa01-r.ovirt.netnerdz...@netnerdz.se's key

2017-03-07T23:05:48Z ERROR IPA server upgrade failed: Inspect
/var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2017-03-07T23:05:48Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, 
in

execute
return_value = self.run()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
line 46, in run
server.upgrade()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1863, in upgrade
upgrade_configuration()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1796, in upgrade_configuration
ca.setup_lightweight_ca_key_retrieval()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", 
line

1400, in setup_lightweight_ca_key_retrieval
self.__setup_lightweight_ca_key_retrieval_kerberos()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", 
line

1431, in __setup_lightweight_ca_key_retrieval_kerberos
os.chmod(keytab, 0o600)

2017-03-07T23:05:48Z DEBUG The ipa-server-upgrade command failed,
exception: OSError: [Errno 2] No such file or directory:
'/etc/pki/pki-tomcat/dogtag.keytab'
2017-03-07T23:05:48Z ERROR Unexpected error - see
/var/log/ipaupgrade.log for details:
OSError: [Errno 2] No such file or directory:
'/etc/pki/pki-tomcat/dogtag.keytab'
2017-03-07T23:05:48Z ERROR The ipa-server-upgrade command failed. See
/var/log/ipaupgrade.log for more information
8<---


Here's the output from the ipa-server-upgrade command:
[root@o-ipa01-r ~]# ipa-server-upgrade
Upgrading IPA:
  [1/8]: saving configuration
  [2/8]: disabling listeners
  [3/8]: enabling DS global lock
  [4/8]: starting directory server
  [5/8]: updating schema

  [6/8]: upgrading server
  [7/8]: stopping directory server
  [8/8]: restoring configuration
Done.
Update complete
Upgrading IPA services
Upgrading the configuration of the IPA services
[Verifying that root certificate is published]
[Migrate CRL publish directory]
CRL tree already moved
/etc/dirsrv/slapd-NETNERDZ-SE/certmap.conf is now managed by IPA. It
will be overwritten. A backup of the original will be made.
[Verifying that CA proxy configuration is correct]
[Verifying that KDC configuration is using ipa-kdb backend]
[Fix DS schema file syntax]
Syntax already fixed
[Removing RA cert from DS NSS database]
RA cert already removed
[Enable sidgen and extdom plugins by default]
[Updating HTTPD service IPA configuration]
[Updating mod_nss protocol versions]
Protocol versions already updated
[Updating mod_nss cipher suite]
[Fixing trust flags in /etc/httpd/alias]
Trust flags already processed
[Exporting KRA agent PEM file]
KRA is not enabled
[Removing self-signed CA]
[Removing Dogtag 9 CA]
[Checking for deprecated KDC configuration files]
[Checking for deprecated backups of Samba 

Re: [Freeipa-users] Read-only replicas?

[Petr Vobornik]

On 03/13/2017 03:17 PM, Stephen wrote:

Is there read-only replica support in freeipa? The use case is a dmz.

Thanks...



Hello Stephen,

No, FreeIPA doesn't support read only replicas yet.

Could you write your use case in more details in:
  https://pagure.io/freeipa/issue/5569
or
 https://bugzilla.redhat.com/show_bug.cgi?id=1291240

It will help us prioritize and know what you actually expect from the 
feature.


Regards,
--
Petr Vobornik

--
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] Issue upgrading freeipa to ipa-server-4.4.0-14.el7.centos.4.x86_64

[Petr Vobornik]

On 03/08/2017 06:06 PM, free...@netnerdz.se wrote:

Hi all!

I'm trying to upgrade my ipa-server to the version in subject and
hitting some bug that seems similar to
https://bugzilla.redhat.com/show_bug.cgi?id=1404910


It is unlikely that it is this bug because the version of IPA with it 
was never released. BUt the error indeed looks similar.




The yum upgrade process took a bit longer than expected so i ctrl+c


This is never a good idea.



it
and executed the command ipa-server-upgrade

The error message from ipa-server-upgrade is:
8<---
IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run
command ipa-server-upgrade manually.
Unexpected error - see /var/log/ipaupgrade.log for details:
OSError: [Errno 2] No such file or directory:
'/etc/pki/pki-tomcat/dogtag.keytab'
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for
more information
[root@o-ipa01-r ~]#
8<---


The lines that indicate an error in the /var/log/ipaupgrade.log file is:
8<---
2017-03-07T23:05:38Z DEBUG stdout=Authenticating as principal
root/ad...@netnerdz.se with password.

2017-03-07T23:05:38Z DEBUG stderr=WARNING: no policy specified for
dogtag/o-ipa01-r.ovirt.netnerdz...@netnerdz.se; defaulting to no policy
add_principal: Principal or policy already exists while creating
"dogtag/o-ipa01-r.ovirt.netnerdz...@netnerdz.se".

2017-03-07T23:05:38Z INFO Retrieving keytab
2017-03-07T23:05:38Z DEBUG Starting external process
2017-03-07T23:05:38Z DEBUG args=kadmin.local -q ktadd -k
/etc/pki/pki-tomcat/dogtag.keytab
dogtag/o-ipa01-r.ovirt.netnerdz...@netnerdz.se -x
ipa-setup-override-restrictions
2017-03-07T23:05:48Z DEBUG Process finished, return code=0
2017-03-07T23:05:48Z DEBUG stdout=Authenticating as principal
root/ad...@netnerdz.se with password.

2017-03-07T23:05:48Z DEBUG stderr=kadmin.local: Server error while
changing dogtag/o-ipa01-r.ovirt.netnerdz...@netnerdz.se's key

2017-03-07T23:05:48Z ERROR IPA server upgrade failed: Inspect
/var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2017-03-07T23:05:48Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute
return_value = self.run()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
line 46, in run
server.upgrade()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1863, in upgrade
upgrade_configuration()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1796, in upgrade_configuration
ca.setup_lightweight_ca_key_retrieval()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
1400, in setup_lightweight_ca_key_retrieval
self.__setup_lightweight_ca_key_retrieval_kerberos()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
1431, in __setup_lightweight_ca_key_retrieval_kerberos
os.chmod(keytab, 0o600)

2017-03-07T23:05:48Z DEBUG The ipa-server-upgrade command failed,
exception: OSError: [Errno 2] No such file or directory:
'/etc/pki/pki-tomcat/dogtag.keytab'
2017-03-07T23:05:48Z ERROR Unexpected error - see
/var/log/ipaupgrade.log for details:
OSError: [Errno 2] No such file or directory:
'/etc/pki/pki-tomcat/dogtag.keytab'
2017-03-07T23:05:48Z ERROR The ipa-server-upgrade command failed. See
/var/log/ipaupgrade.log for more information
8<---


Here's the output from the ipa-server-upgrade command:
[root@o-ipa01-r ~]# ipa-server-upgrade
Upgrading IPA:
  [1/8]: saving configuration
  [2/8]: disabling listeners
  [3/8]: enabling DS global lock
  [4/8]: starting directory server
  [5/8]: updating schema

  [6/8]: upgrading server
  [7/8]: stopping directory server
  [8/8]: restoring configuration
Done.
Update complete
Upgrading IPA services
Upgrading the configuration of the IPA services
[Verifying that root certificate is published]
[Migrate CRL publish directory]
CRL tree already moved
/etc/dirsrv/slapd-NETNERDZ-SE/certmap.conf is now managed by IPA. It
will be overwritten. A backup of the original will be made.
[Verifying that CA proxy configuration is correct]
[Verifying that KDC configuration is using ipa-kdb backend]
[Fix DS schema file syntax]
Syntax already fixed
[Removing RA cert from DS NSS database]
RA cert already removed
[Enable sidgen and extdom plugins by default]
[Updating HTTPD service IPA configuration]
[Updating mod_nss protocol versions]
Protocol versions already updated
[Updating mod_nss cipher suite]
[Fixing trust flags in /etc/httpd/alias]
Trust flags already processed
[Exporting KRA agent PEM file]
KRA is not enabled
[Removing self-signed CA]
[Removing Dogtag 9 CA]
[Checking for deprecated KDC configuration files]
[Checking for deprecated backups of Samba configuration files]
[Setting up Firefox extension]
[Add missing CA DNS records]
IPA CA DNS records already processed
[Removing deprecated DNS configuration options]
[Ensuring minimal number of connections]
[Enabling serial autoincrement in DNS]