[Freeipa-users] Split Horizon DNS config

[Christoph Kaminski]

Hi

can someone validate this config for bind + split horizon (only the views 
part):

acl internal {
127.0.0.1;
172.16.0.0/12; 
};

view "internal"
{
match-clients   { internal; };
recursion yes; 

dynamic-db "ipa" { 
library "ldap.so";  
arg "uri ldapi://%2fvar%2frun%2fslapd-HSO.socket"; 
  
arg "base cn=dns, dc=hso";   
arg "fake_mname ipa-2.mgmt.hss.int.";
arg "auth_method sasl";
arg "sasl_mech GSSAPI";
arg "sasl_user DNS/ipa-2.mgmt.hss.int";
arg "serial_autoincrement yes";
};

zone "." IN {
type hint;
file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

};

view "external"
{
match-clients   { any; };
recursion yes;

zone "mgmt.hss.int" {
type master;
file "mgmt.hss.int.db";
};

zone "in-addr.arpa" {
type forward;
forward only; 
forwarders { 172.16.8.210; };
};

zone "." IN {
type hint;
file "named.ca";
};

include "/etc/named.rfc1912.zones"; 
include "/etc/named.root.key";
};

it works but its a little bit unclean hack IMHO. Bind 9.9 in rhel7.1 
doesnt support 'in-view' thats the reason why I use a the same host but 
the ip from internal acl her:

zone "in-addr.arpa" {
type forward;
forward only; 
forwarders { 172.16.8.210; };
};

is there something what can make problems?

MfG
Christoph Kaminski



-- 
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] interesting Kerberos issue

[Janelle]

On 5/4/15 6:06 PM, Nathaniel McCallum wrote:

On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:

Happy Star Wars Day!
May the Fourth be with you!

So I have a strange Kerberos problem trying to figure out.  On a
CLIENT,  (CentOS 7.1) if I login to account "usera" they get a
ticket as
expected.  However, if I login to a 6.6 client, it doesn't seem to
work.
Both were enrolled the same, obviously one is newer.

Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login
as
root, bypassing kerberos, and then do "kinit admin" it works just
fine.
But if I do "kinit usera" I get:

kinit: Generic preauthentication failure while getting initial
credentials

Which makes no sense. The account works with a 7.1 client but not a
6.x
client?? And yet "admin" works, no matter what. What am I missing
here?

If I had to guess, usera is enabled for OTP-only login. Is that
correct?

If so, clients require RHEL 7.1 for OTP support. Also, the error you
are getting is the result of not enabling FAST support for OTP
authentication (see the -T option).

Nathaniel
Ok, this did give me an idea (Thanks Nathaniel)  -- the account was set 
for BOTH "password" and OTP.
Apparently setting both does nothing. Yes a user can login with their 
password-only, but trying to use kinit does not work.


I am not sure I understand where the FAST support or the -T option is to 
be applied. On kinit? That does not seem correct. Perhaps I am 
misunderstanding this option?


~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

[Freeipa-users] regex with sudo commands

[Megan .]

Good Evening!

I'm running 3.0.0-42 on Centos 6.6.

I setup a number of sudo commands today with regular expressions and
now users seem to be having issues running any sudo command.  Are
there any known issues with having regex in sudo commands within the
IPA server?

Here is an example of a sudo rule I have setup.  When my user runs
sudo -ll he only sees the below command, and he should have a large
number of commands available (like /sbin/service httpd restart)

SSSD Role: deploy for UAT
RunAsUsers: appusr
Commands:
/usr/bin/python /usr/share/appusr/onworld-tools/scripts/configure.py
-l [a-zA-Z0-9\-_/]* -e EPSG[0-9][0-9][0-9][0-9] -t [a-z]*
/usr/share/appusr/apache-ant-1.9.4/bin/ant -f
/usr/share/appusr/onworld-tools/scripts/config_deploy.xml
deploy-[a-zA-Z0-9\-]  -Denv=uat


I also purged /var/lib/sss/db and restated sssd thinking it might be
related to caching but it didn't help.

Thanks in advance!

-- 
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] interesting Kerberos issue

[Dmitri Pal]

On 05/04/2015 09:22 PM, Janelle wrote:

On 5/4/15 6:06 PM, Nathaniel McCallum wrote:

On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:

Happy Star Wars Day!
May the Fourth be with you!

So I have a strange Kerberos problem trying to figure out.  On a
CLIENT,  (CentOS 7.1) if I login to account "usera" they get a
ticket as
expected.  However, if I login to a 6.6 client, it doesn't seem to
work.
Both were enrolled the same, obviously one is newer.

Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login
as
root, bypassing kerberos, and then do "kinit admin" it works just
fine.
But if I do "kinit usera" I get:

kinit: Generic preauthentication failure while getting initial
credentials

Which makes no sense. The account works with a 7.1 client but not a
6.x
client?? And yet "admin" works, no matter what. What am I missing
here?

If I had to guess, usera is enabled for OTP-only login. Is that
correct?

If so, clients require RHEL 7.1 for OTP support. Also, the error you
are getting is the result of not enabling FAST support for OTP
authentication (see the -T option).

Nathaniel
Apparently I am not being clear. The user account can login all over 
the place with no problems -- RHEL 7.1 or 6.6.  HOWEVER, on 7.1, a 
login provides a direct tgt, but no matter what you do on any other 
host using kinit (after logging in with an SSH key perhaps or as 
another user) and even know the password, you get this error.


Again, logging in with the password, not OTP, works just fine.

Confusing,
~J


Do you get any SELinux AVCs?
May be it is an issue of the ticket cache permissions/labels?

--
Thank you,
Dmitri Pal

Director of Engineering for IdM portfolio
Red Hat, Inc.

--
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] interesting Kerberos issue

[Janelle]

On 5/4/15 6:06 PM, Nathaniel McCallum wrote:

On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:

Happy Star Wars Day!
May the Fourth be with you!

So I have a strange Kerberos problem trying to figure out.  On a
CLIENT,  (CentOS 7.1) if I login to account "usera" they get a
ticket as
expected.  However, if I login to a 6.6 client, it doesn't seem to
work.
Both were enrolled the same, obviously one is newer.

Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login
as
root, bypassing kerberos, and then do "kinit admin" it works just
fine.
But if I do "kinit usera" I get:

kinit: Generic preauthentication failure while getting initial
credentials

Which makes no sense. The account works with a 7.1 client but not a
6.x
client?? And yet "admin" works, no matter what. What am I missing
here?

If I had to guess, usera is enabled for OTP-only login. Is that
correct?

If so, clients require RHEL 7.1 for OTP support. Also, the error you
are getting is the result of not enabling FAST support for OTP
authentication (see the -T option).

Nathaniel
Apparently I am not being clear. The user account can login all over the 
place with no problems -- RHEL 7.1 or 6.6.  HOWEVER, on 7.1, a login 
provides a direct tgt, but no matter what you do on any other host using 
kinit (after logging in with an SSH key perhaps or as another user) and 
even know the password, you get this error.


Again, logging in with the password, not OTP, works just fine.

Confusing,
~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] interesting Kerberos issue

[Nathaniel McCallum]

On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:
> Happy Star Wars Day!
> May the Fourth be with you!
> 
> So I have a strange Kerberos problem trying to figure out.  On a 
> CLIENT,  (CentOS 7.1) if I login to account "usera" they get a 
> ticket as 
> expected.  However, if I login to a 6.6 client, it doesn't seem to 
> work. 
> Both were enrolled the same, obviously one is newer.
> 
> Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login 
> as 
> root, bypassing kerberos, and then do "kinit admin" it works just 
> fine. 
> But if I do "kinit usera" I get:
> 
> kinit: Generic preauthentication failure while getting initial 
> credentials
> 
> Which makes no sense. The account works with a 7.1 client but not a 
> 6.x 
> client?? And yet "admin" works, no matter what. What am I missing 
> here?

If I had to guess, usera is enabled for OTP-only login. Is that
correct?

If so, clients require RHEL 7.1 for OTP support. Also, the error you
are getting is the result of not enabling FAST support for OTP
authentication (see the -T option).

Nathaniel

-- 
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 4.1.4 DNS notifications not being sent to slaves

[nathan]

freeipa-admintools.x86_64  4.1.4-1.el7.centos   
@mkosek-freeipa
freeipa-client.x86_64  4.1.4-1.el7.centos   
@mkosek-freeipa
freeipa-python.x86_64  4.1.4-1.el7.centos   
@mkosek-freeipa
freeipa-server.x86_64  4.1.4-1.el7.centos   
@mkosek-freeipa
freeipa-server-trust-ad.x86_64 4.1.4-1.el7.centos   
@mkosek-freeipa

bind.x86_6432:9.9.4-20.el7.centos.pkcs11
@mkosek-freeipa
bind-dyndb-ldap.x86_64 6.1-1.el7.centos 
@mkosek-freeipa
bind-libs.x86_64   32:9.9.4-20.el7.centos.pkcs11
@mkosek-freeipa
bind-libs-lite.x86_64  32:9.9.4-20.el7.centos.pkcs11
@mkosek-freeipa
bind-license.noarch32:9.9.4-20.el7.centos.pkcs11
@mkosek-freeipa
bind-pkcs11.x86_64 32:9.9.4-20.el7.centos.pkcs11
@mkosek-freeipa
bind-pkcs11-libs.x86_6432:9.9.4-20.el7.centos.pkcs11
@mkosek-freeipa
bind-pkcs11-utils.x86_64   32:9.9.4-20.el7.centos.pkcs11
@mkosek-freeipa

And for reference here are the relevant A and NS records from my domain

@ NS dc1.mydomain.net.
@ NS dc2.mydomain.net.
@ NS dns1.mydomain.net.
dns1 A 10.21.0.14

> Hello!
>
> On 2.5.2015 17:12, Nathan Peters wrote:
>> The last 3 sentences of my original post refer to me adding the NS
>> records for
>> the slave.  Is that what you mean?
>>
>> "I have also ensured that the slave hostname and IP are in FreeIPA DNS.
>> I
>> have also added an NS entry pointing to the slave."
>
> Which version of FreeIPA and bind-dyndb-ldap are you using?
>
> I will look into it.
>
> Petr^2 Spacek
>
>
>> -Original Message- From: Baird, Josh
>> Sent: Saturday, May 02, 2015 7:33 AM
>> To: 'nat...@nathanpeters.com' ; freeipa-users@redhat.com
>> Subject: RE: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being
>> sent to
>> slaves
>>
>> Is the PowerDNS slave in the NS RRSet for the IPA domain?
>> Unfortuantely,
>> bind-dyndb-ldap does not support 'also-notify' which would allow us to
>> send
>> notifies each time a zone update occurs to slave servers that are not in
>> the
>> RRSet [1].  To compensate for this in my environment, I had to lower the
>> 'refresh' timer on the IPA zone.
>>
>> [1] https://fedorahosted.org/bind-dyndb-ldap/ticket/152
>>
>> -Original Message-
>> From: freeipa-users-boun...@redhat.com
>> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of
>> nat...@nathanpeters.com
>> Sent: Friday, May 1, 2015 8:20 PM
>> To: freeipa-users@redhat.com
>> Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent
>> to slaves
>>
>> I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas.
>>
>> I also have another host running PowerDNS serving as a slave.
>> The FreeIPA servers are setup to allow transfers to the slave by IP.
>> When
>> adding the zone, the slave transfered it properly.
>>
>> However, when I update the zone in FreeIPA, although the serial number
>> changes, in the /var/log/messages I only see an attempt to transfer to
>> the
>> second IPA server, and not the slave.  This is the only log entry :
>>
>> May  2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending
>> notifies
>> (serial 1430528817) May  2 01:06:57 dc1 named-pkcs11[5897]: client
>> 10.178.0.99#29832: received notify for zone 'mydomain.net'
>>
>> I have restarted all services using ipactl restart several times.  I
>> have also
>> ensured that the slave hostname and IP are in FreeIPA DNS.  I have also
>> added
>> an NS entry pointing to the slave.
>>
>> According to the FreeIPA manual, once that NS entry is added, any zone
>> updates
>> should trigger a notify, but still the only notifications go out to
>> FreeIPA
>> servers and nothing else.
>>
>> Any idea how to fix this so FreeIPA notifies non IPA servers?  I'm
>> pretty sure
>> I've followed all the instructions to the letter on this one...
>>
>>
>> --
>> 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
>
>
> --
> 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
>



-- 
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] Removing REALM requirement and home directory location

[Dmitri Pal]

On 05/04/2015 02:50 PM, Redmond, Stacy wrote:


I am running a RHEL7 IPA Server ipa-server 3.3.3-28

RHEL6 clients running IPA Client 3.0.0-42

I have setup an AD trust which works great, however I want to make it 
so the users don't have to use @realm to login and that their home 
directory does not default to /home/realm/username


AD   sbx.local

IPA unix.sbx.local



man sssd.conf
/default_domain_suffix



Works great

User login:  ssh username@realm@hostname

$ ssh aduser1@s...@linuxtest1.sbx.local

aduser1@s...@linuxtest1.sbx.local's password:

Last login: Fri May  1 09:36:53 2015 from xxx.xxx.xxx.xxx

Could not chdir to home directory /home/sbx.local/aduser1: No such 
file or directory


$

Any and all help is appreciated.






--
Thank you,
Dmitri Pal

Director of Engineering for IdM portfolio
Red Hat, Inc.

-- 
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] interesting Kerberos issue

[Janelle]

On 5/4/15 1:02 PM, Simo Sorce wrote:

On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:

Happy Star Wars Day!
May the Fourth be with you!

So I have a strange Kerberos problem trying to figure out.  On a
CLIENT,  (CentOS 7.1) if I login to account "usera" they get a ticket as
expected.  However, if I login to a 6.6 client, it doesn't seem to work.
Both were enrolled the same, obviously one is newer.

Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as
root, bypassing kerberos, and then do "kinit admin" it works just fine.
But if I do "kinit usera" I get:

kinit: Generic preauthentication failure while getting initial credentials

Which makes no sense. The account works with a 7.1 client but not a 6.x
client?? And yet "admin" works, no matter what. What am I missing here?

Have you recently changed the user password ?
If so this symptom may indicate you are having replication issues
between your servers, and one of the client is hitting the server that
didn't get the keys replicated to it.

Simo.

None of the above -- All the servers are replicated. The user account (a 
test account) has not changed PW in weeks and works everywhere else.  I 
nee to increase some logging. I guess the strange  part is as mentioned 
-- it works if you login directly to the 7.1 client, no matter which 
server it is pointed at.


~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] interesting Kerberos issue

[Simo Sorce]

On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:
> Happy Star Wars Day!
> May the Fourth be with you!
> 
> So I have a strange Kerberos problem trying to figure out.  On a 
> CLIENT,  (CentOS 7.1) if I login to account "usera" they get a ticket as 
> expected.  However, if I login to a 6.6 client, it doesn't seem to work. 
> Both were enrolled the same, obviously one is newer.
> 
> Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as 
> root, bypassing kerberos, and then do "kinit admin" it works just fine. 
> But if I do "kinit usera" I get:
> 
> kinit: Generic preauthentication failure while getting initial credentials
> 
> Which makes no sense. The account works with a 7.1 client but not a 6.x 
> client?? And yet "admin" works, no matter what. What am I missing here?

Have you recently changed the user password ?
If so this symptom may indicate you are having replication issues
between your servers, and one of the client is hitting the server that
didn't get the keys replicated to it.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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] Removing REALM requirement and home directory location

[Redmond, Stacy]

I am running a RHEL7 IPA Server ipa-server 3.3.3-28
RHEL6 clients running IPA Client 3.0.0-42

I have setup an AD trust which works great, however I want to make it so the 
users don't have to use @realm to login and that their home directory does not 
default to /home/realm/username

AD   sbx.local
IPA   unix.sbx.local


Works great
User login:  ssh username@realm@hostname

$ ssh aduser1@s...@linuxtest1.sbx.local
aduser1@s...@linuxtest1.sbx.local's password:
Last login: Fri May  1 09:36:53 2015 from xxx.xxx.xxx.xxx

Could not chdir to home directory /home/sbx.local/aduser1: No such file or 
directory
$

Any and all help is appreciated.
-- 
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] interesting Kerberos issue

[Dmitri Pal]

On 05/04/2015 11:49 AM, Janelle wrote:

Happy Star Wars Day!
May the Fourth be with you!

So I have a strange Kerberos problem trying to figure out.  On a 
CLIENT,  (CentOS 7.1) if I login to account "usera" they get a ticket 
as expected.  However, if I login to a 6.6 client, it doesn't seem to 
work. Both were enrolled the same, obviously one is newer.


Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login 
as root, bypassing kerberos, and then do "kinit admin" it works just 
fine. But if I do "kinit usera" I get:


kinit: Generic preauthentication failure while getting initial 
credentials


Which makes no sense. The account works with a 7.1 client but not a 
6.x client?? And yet "admin" works, no matter what. What am I missing 
here?


~J

This is really strange. What does happen on the server when you try 
kinit usera? Have you checked the KDC log?
Look at the usera entry, may be there is some strange attribute there 
that causes this failure. Compare with admin entry. May be it will shed 
some light.


--
Thank you,
Dmitri Pal

Director of Engineering for IdM portfolio
Red Hat, Inc.

--
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] interesting Kerberos issue

[Janelle]

Happy Star Wars Day!
May the Fourth be with you!

So I have a strange Kerberos problem trying to figure out.  On a 
CLIENT,  (CentOS 7.1) if I login to account "usera" they get a ticket as 
expected.  However, if I login to a 6.6 client, it doesn't seem to work. 
Both were enrolled the same, obviously one is newer.


Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as 
root, bypassing kerberos, and then do "kinit admin" it works just fine. 
But if I do "kinit usera" I get:


kinit: Generic preauthentication failure while getting initial credentials

Which makes no sense. The account works with a 7.1 client but not a 6.x 
client?? And yet "admin" works, no matter what. What am I missing here?


~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] Questions about nsslapd-sizelimit

[John Desantis]

Rob,

Thanks for your reply.

My predecessor had wrote code to pull user entries from the realm in
order to verify that:

1.)  A home directory is created (if not already) and apply the
correct ownership;
2.)  A work directory (Lustre) is created (if not already) and apply
the correct ownership.

Given what you've said, I'll perform a work-around within the code to
get a list of active users from a database table vs. the current
method.

John DeSantis

2015-05-04 9:53 GMT-04:00 Rob Crittenden :
> John Desantis wrote:
>> Hello all!
>>
>> I believe I may be falling victim to the nsslapd-sizelimit's default
>> setting of 2,000.
>>
>> I've been wondering why some JSON calls to IPA (3.0.37, user_find)
>> have been failing to show all user accounts in the results.  Checking
>> the FreeIPA admin UI, I can clearly find the users in question, but no
>> matter what changes I set in the UI on the the console with search
>> record limits and time limits, only 2,000 entries are ever returned.
>> A final test this morning by adding an account via the UI did not
>> augment the 2,000 entries returned in the user list;  searching for
>> the user on the console with 'ipa user-show y* --all' and via the
>> search frame in the UI found the user.
>>
>> Looking over the documentation, it's stated that you can use the UI to
>> update the limits.  However, the limit is already set at 10,000 for
>> the number of records to be returned, and the time limit is set at 60.
>> The current dse.ldiff states that the nsslapd-sizelimit is 2,000.
>>
>> Is it possible that IPA isn't respecting this value since the constant
>> number is 2,000?  Is it safe to change this value via an ldapmodify?
>>
>> Thank you!
>> John DeSantis
>>
>
> Why do you need to return > 2000 users at one time?
>
> IPA purposely limits the number of entries returned by default (100)
> specifically to discourage enumeration which is expensive.
>
> It is safe to modify this value using ldapmodify. Increasing the value
> is not recommended.
>
> 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] Questions about nsslapd-sizelimit

[Rob Crittenden]

John Desantis wrote:
> Hello all!
> 
> I believe I may be falling victim to the nsslapd-sizelimit's default
> setting of 2,000.
> 
> I've been wondering why some JSON calls to IPA (3.0.37, user_find)
> have been failing to show all user accounts in the results.  Checking
> the FreeIPA admin UI, I can clearly find the users in question, but no
> matter what changes I set in the UI on the the console with search
> record limits and time limits, only 2,000 entries are ever returned.
> A final test this morning by adding an account via the UI did not
> augment the 2,000 entries returned in the user list;  searching for
> the user on the console with 'ipa user-show y* --all' and via the
> search frame in the UI found the user.
> 
> Looking over the documentation, it's stated that you can use the UI to
> update the limits.  However, the limit is already set at 10,000 for
> the number of records to be returned, and the time limit is set at 60.
> The current dse.ldiff states that the nsslapd-sizelimit is 2,000.
> 
> Is it possible that IPA isn't respecting this value since the constant
> number is 2,000?  Is it safe to change this value via an ldapmodify?
> 
> Thank you!
> John DeSantis
> 

Why do you need to return > 2000 users at one time?

IPA purposely limits the number of entries returned by default (100)
specifically to discourage enumeration which is expensive.

It is safe to modify this value using ldapmodify. Increasing the value
is not recommended.

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] CA replicas on all?

[Rob Crittenden]

Janelle wrote:
> Hi all,
> 
> Just wondering if there are issues with running CA replicas on all the 
> servers? Are there maybe performance issues or anything that I might not be 
> aware of?

The only downside I can think of is resources used (RAM & disk) and
slightly more administration regarding replication monitoring (both by
you and 389-ds).

Unless you are constantly creating and deleting certs the replication
load should be extremely low once you have your environment stable.

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

[Freeipa-users] using pathlen:0 for freeipa's CA certificate?

[Harald Dunkel]

Hi folks,

Instead of a self-signed certificate I would like to use an external
CA to sign freeipa's CSR ("ipa-server-install --external-ca").
Question:

Is pathlen:0, e.g.

basicConstraints=critical,CA:TRUE, pathlen:0

sufficient for freeipa's CA certificate?


Regards
Harri

-- 
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] Questions about nsslapd-sizelimit

[John Desantis]

Hello all!

I believe I may be falling victim to the nsslapd-sizelimit's default
setting of 2,000.

I've been wondering why some JSON calls to IPA (3.0.37, user_find)
have been failing to show all user accounts in the results.  Checking
the FreeIPA admin UI, I can clearly find the users in question, but no
matter what changes I set in the UI on the the console with search
record limits and time limits, only 2,000 entries are ever returned.
A final test this morning by adding an account via the UI did not
augment the 2,000 entries returned in the user list;  searching for
the user on the console with 'ipa user-show y* --all' and via the
search frame in the UI found the user.

Looking over the documentation, it's stated that you can use the UI to
update the limits.  However, the limit is already set at 10,000 for
the number of records to be returned, and the time limit is set at 60.
The current dse.ldiff states that the nsslapd-sizelimit is 2,000.

Is it possible that IPA isn't respecting this value since the constant
number is 2,000?  Is it safe to change this value via an ldapmodify?

Thank you!
John DeSantis

-- 
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] Setup of SRV records for new domains

[Petr Spacek]

On 4.5.2015 14:59, Brian Topping wrote:
> Ah, thanks! I see what's going on now. That helps a lot.
> 
> I think what I was missing was the reluctance for IPA to serve domains
> that are not proper TLDs. I generally maintain internal security domains
> with an invented TLD since they are secure by definition. When I tried
> that today, it was unable to auto discover on this domain and I
> attributed it to the lack of SRV records.

Generally it is better to use 'internal.example.com.' instead of invented
TLDs like 'mytld.'.

FreeIPA can work with 'invented' TLDs if you have properly configured DNS
but it is usually a nightmare. That is the reason why it is strictly
discouraged.

Also, 'invented' TLDs cannot work with DNSSEC validation unless you
distribute trust anchor to every single DNSSEC validator. This is one more
reason for using proper sub-domains instead of invented TLDs.

Let me know if you want to hear mode details about that. Have a nice day!

Petr^2 Spacek

> Brian
> 
>> On May 4, 2015, at 3:43 PM, Petr Spacek  wrote:
>> 
>> On 4.5.2015 10:23, Brian Topping wrote:
>>> On second view, I think my brain misfiled this. Maybe the records
>>> were not set up automatically, another DNS domain I thought had the
>>> records in fact do not.
>>> 
>>> As a feature request, it seems like if a domain is added to "Domain 
>>> Realms", it should also get the appropriate records for client 
>>> autodiscovery.
>> 
>> It is actually not necessary to create all the SRV records in all
>> domains.
>> 
>> Client auto-discovery is using the TXT record which is added
>> automatically and the _kerberos TXT record is like 'redirect'.
>> 
>> The procedure is: - client client1.sub.example.com
>> . searches for record 
>> _kerberos.sub.example.com  TXT -
>> _kerberos.sub.example.com  TXT
>> contains realm name "EXAMPLE.COM " - now the
>> client knows that all the SRV records are inside example.com
>> . domain - SRV records from example.com
>> . are used from now on
>> 
>> AFAIK this is very standard Kerberos behavior so it should work for
>> all standard-compliant clients.
>> 
>> Petr^2 Spacek
>> 
>>> Cheers, Brian
>>> 
 On May 4, 2015, at 3:03 PM, Brian Topping
  wrote:
 
 I just added a new domain and didn't see the SRV records added for
 it. There is a TXT record, but none of the SRV records that are in
 other DNS domains.
 
 After going to the "Realm Domains tab of the "IPA Server" 
 configuration, I see that the new domain was already added there,
 so I removed it and added it back, hoping that might cause the SRV
 records to be added, but no luck.
 
 Any ideas what I should check for?
 
 Thanks, Brian

-- 
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] Setup of SRV records for new domains

[Brian Topping]

Ah, thanks! I see what's going on now. That helps a lot.

I think what I was missing was the reluctance for IPA to serve domains that are 
not proper TLDs. I generally maintain internal security domains with an 
invented TLD since they are secure by definition. When I tried that today, it 
was unable to auto discover on this domain and I attributed it to the lack of 
SRV records.

Thanks for setting me straight!

Brian

> On May 4, 2015, at 3:43 PM, Petr Spacek  wrote:
> 
> On 4.5.2015 10:23, Brian Topping wrote:
>> On second view, I think my brain misfiled this. Maybe the records were
>> not set up automatically, another DNS domain I thought had the records in
>> fact do not.
>> 
>> As a feature request, it seems like if a domain is added to "Domain
>> Realms", it should also get the appropriate records for client
>> autodiscovery.
> 
> It is actually not necessary to create all the SRV records in all domains.
> 
> Client auto-discovery is using the TXT record which is added automatically
> and the _kerberos TXT record is like 'redirect'.
> 
> The procedure is:
> - client client1.sub.example.com . searches 
> for record
> _kerberos.sub.example.com  TXT
> - _kerberos.sub.example.com  TXT contains 
> realm name "EXAMPLE.COM "
> - now the client knows that all the SRV records are inside example.com 
> . domain
> - SRV records from example.com . are used from now on
> 
> AFAIK this is very standard Kerberos behavior so it should work for all
> standard-compliant clients.
> 
> Petr^2 Spacek
> 
>> Cheers, Brian
>> 
>>> On May 4, 2015, at 3:03 PM, Brian Topping 
>>> wrote:
>>> 
>>> I just added a new domain and didn't see the SRV records added for it.
>>> There is a TXT record, but none of the SRV records that are in other
>>> DNS domains.
>>> 
>>> After going to the "Realm Domains tab of the "IPA Server"
>>> configuration, I see that the new domain was already added there, so I
>>> removed it and added it back, hoping that might cause the SRV records
>>> to be added, but no luck.
>>> 
>>> Any ideas what I should check for?
>>> 
>>> Thanks, Brian
> 
> --
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
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] CA replicas on all?

[Dmitri Pal]

On 05/02/2015 05:12 PM, Janelle wrote:

Hi all,

Just wondering if there are issues with running CA replicas on all the servers? 
Are there maybe performance issues or anything that I might not be aware of?

~Janelle




I do not think we have any data of any negative properties of such setup.
We allow not running CA everywhere because there were requests to allow 
a subset but the initial design assumed a CA on every replica.


--
Thank you,
Dmitri Pal

Director of Engineering for IdM portfolio
Red Hat, Inc.

--
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] Common Name for the ipa-cacert-manage command

[Dmitri Pal]

On 04/30/2015 06:52 PM, William Graboyes wrote:

I have to agree with Benjamen here.

I guess it is time to get deep into API documentation.  This is a hell of a lot 
of hoops to jump through just so that users who don't have shell access can 
easily change their passwords without having to see a scare page.  Distributing 
the IPA CA is not an option at this point, as we have a very odd desktop 
support model.  I thought all of this was to be fixed in 4.1, which is why I 
went 4.1... and now nothing has changed... and I am back to square 1.


I am not sure I understand your expectations. There are really no other 
options.
You can go CA-less and have Puppet or similar to replace your certs when 
they expire.
You can use IPA CA and let certmonger do the work. IPA CA can be root or 
chained.
It is not clear what else we can do other than finish the automatic 
distribution of certs when key rotation happens.




This is the only, and I am serious here, the only gating factor for FreeIPA going into 
production.  The self-signed certs on the UI.  It really isn't safe or secure to tell 
users to "Just trust the self signed cert."  You create an easy vector for 
users to get sucked into a phishing trap.

Next question, Has anyone made or documented an external password change 
program for freeipa?



On 4/30/15 3:28 PM, Benjamen Keroack wrote:

With respect, neither option is realistic in the common case. Unless I'm
mistaken, a CA-less installation will break in ~1 year when host
certificates expire and are not automatically renewed via certmonger.
Option 2 (sub-CA) is, as far as I can tell, also not feasible since no
public CA will sell subordinate CA certificates commercially. At least not
that I can find.

In our case, the only option is to resign ourselves to using self-signed
certificates for the UI. End users can import IPA CA root cert if they
choose.

On Thu, Apr 30, 2015 at 2:45 PM, Dmitri Pal  wrote:


On 04/30/2015 04:50 PM, William Graboyes wrote:


Let me ask this a different way.

What is the easiest method of using a trusted third party cert for the
web UI?


Make IPA CA-less with just certs from that 3rd party CA installed or make
IPA trust that CA and be a sub CA.


https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#install-ca-options




Running IPA 4.1.0 on Centos 7.

Thanks,
Bill
On 4/30/15 1:44 PM, Rob Crittenden wrote:


William Graboyes wrote:


Hi list,

The end goal is to eliminate self signed certs from user interaction
with FreeIPA, without having to roll out changes to each user in the
house (and remote locations).  So basically changing the CA to a
trusted CA that will not bring "scare" the users with "Site security
cannot be verified, return to safety."

The problem with the CN is that when it is read from the CSR the
CN="Certificate Authority".  Which is not an acceptable CN according
to the tool we use for generating certs, The tool we use expects a CN
of something along the lines of example.com.


That sounds odd. The CN of a CA doesn't represent a machine or a
specific domain, it represents itself. Granted Certificate Authority
isn't all that unique a name either, but it's what we defaulted to, IIRC
based on the dogtag defaults.

Changing it might have other odd side-effects too as it's hardcoded in a
few other places. I'm not exactly sure what would break, if anything.

It sounds like your tool is issuing a server cert, not a CA cert. A
server cert traditionally has used cn=FQDN,. That
doesn't really apply to a CA.

So it's changeable if you hack some installer code, but there be dragons.

rob


Thanks,
Bill

On 4/21/15 2:55 PM, Rob Crittenden wrote:


William Graboyes wrote:


Hi List,

I am having yet another issue, when I run the following command:
ipa-cacert-manage renew --external-ca

It does output the CSR, however the CN is not a valid name
(Certificate Authority).  Is it possible to change the output of
this command to use an external CA that requires a proper common
name to be in the CSR?

What I am trying to do is change from the internal self signed
certs to an external CA signing system.

  What isn't valid about the name?

This would make the IPA CA a subordinate of the external CA. Is
that what you want?
rob





--
Thank you,
Dmitri Pal

Director of Engineering for IdM portfolio
Red Hat, Inc.


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









--
Thank you,
Dmitri Pal

Director of Engineering for IdM portfolio
Red Hat, Inc.

--
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] Web ui error “Your session has expired. Please re-login.” from a browser on a remote client.

[Petr Vobornik]

On 05/04/2015 07:53 AM, Petr Spacek wrote:

On 30.4.2015 14:39, Christopher Lamb wrote:

Hi Petr

Thanks, we solved this issue and reported that back on this thread. The
troubleshooting guide has even been updated as a result.

https://www.redhat.com/archives/freeipa-users/2015-April/msg00605.html

Your suggestion has however hit the nail on the head - the problem was
clock skew between the Server hosting freeIPA and the workstations.


Petr, could we detect this situation in initial Javascript?

I can imagine that server sends its current UTC time to the browser while
login page is loading and then client could compare (local UTC) - (server UTC)
and scream if time difference is greater than ... 5 minutes or so?



I think it's possible.

Server sends HTTP response date header[1] with format [2].

In browser:

   var date = new Date(xhr.getResponseHeader('Date'));
   var diff = Date.now() - date.getTime();
   var minutes = diff / 1000 / 60;

new ticket: https://fedorahosted.org/freeipa/ticket/5015

[1] https://tools.ietf.org/html/rfc2616#section-14.18
[2] https://tools.ietf.org/html/rfc2616#section-3.3.1
--
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] Access to IPA Web-UI with different domain names

[Tomas Babej]

On 05/04/2015 12:32 PM, Tomas Babej wrote:



On 04/27/2015 06:06 PM, David Dimovski wrote:

Hi Folks,
does somebody have a best practice, how to access the IPA Web-UI with 
different domain names?


Example:
Our IPA 4.1 have two different IPs (extern and intern) with two 
domain names. The web gui is only accessible from the domain name, 
which IPA was registered with (intern domain name). When trying to 
access with the extern domain name, IPA is rewriting to the intern 
domain name.


After disabling the rewriting, the web ui is accessible from the two 
domain names, but the login is not possible from the extern domain 
name (only intern domain name), getting the following error:

Logout session expired.

Does sombody has a idea or a clue?

Many thanks in advance!

Best regards
David




Hi,

one possible solution would be to setup a reverse proxy with the 
external domain name, which would be passing the requests from the 
external world to the internal IPA sever.


However, the proxy would need to circumvent our XSS protection and 
rewrite the HTTP_REFERRER header to the internal hostname.


I haven't tested it, so maybe additional issues would come up.

Tomas




For the record, Alexander pointed out that this would not work well, as 
connections passed by the proxy to the internal IPA instance would be 
encrypted using the external's server HTTP service ticket.


A proper solution here would be to create an IPA replica with the 
external hostname.


Tomas
-- 
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] Access to IPA Web-UI with different domain names

[Tomas Babej]

On 04/27/2015 06:06 PM, David Dimovski wrote:

Hi Folks,
does somebody have a best practice, how to access the IPA Web-UI with 
different domain names?


Example:
Our IPA 4.1 have two different IPs (extern and intern) with two domain 
names. The web gui is only accessible from the domain name, which IPA 
was registered with (intern domain name). When trying to access with 
the extern domain name, IPA is rewriting to the intern domain name.


After disabling the rewriting, the web ui is accessible from the two 
domain names, but the login is not possible from the extern domain 
name (only intern domain name), getting the following error:

Logout session expired.

Does sombody has a idea or a clue?

Many thanks in advance!

Best regards
David




Hi,

one possible solution would be to setup a reverse proxy with the 
external domain name, which would be passing the requests from the 
external world to the internal IPA sever.


However, the proxy would need to circumvent our XSS protection and 
rewrite the HTTP_REFERRER header to the internal hostname.


I haven't tested it, so maybe additional issues would come up.

Tomas
-- 
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] deleting ipa user

[Tomas Babej]

On 04/30/2015 02:31 PM, Andy Thompson wrote:

It appears that f82 is the user object and f87 is the group object.  So you are

right, I don't think f82 is what we were looking for, it just happened to have
the username in it when I grepped without filtering the uniqueid.  I'm not
sure why it was having problems with the user group object, but I don't have
individual group objects showing up for any local accounts I've created.
You are right. I think the private group of a user is/should be deleted at the
same time when you delete a user.

Is it normal that private groups do not show up in the user group listing or 
with ipa group-find commands?  I thought I remembered seeing them on a freeipa 
3 installation but I've checked a couple 4 installs and they don't show up.


User private groups should not show up in the results of ipa group-* 
commands. I'm not sure what you meant by "user group listing",

but they should show up when running the "id" command.



I just had a random issue a little bit ago with another account when I checked 
the user groups in the web interface it popped with an unknown error dialog.  I 
have not been able to reproduce it again and don't see anything in the error 
logs or access log which would indicate any problems.


All that being said, I put 389-ds-base-1.3.3.1-16.el7_1.x86_64 on the box

yesterday and the error has not shown since.  So I'm not sure if it was
because of the minor upgrade or cycling the daemon.
The logs gave a lot of information but without a test case it could be difficult
to identify the RC.
Now as I mentioned I hit (with a non systematic test case) an other bug when
deleting a user. It was impossible to remove the entry/group. In this bug I
tested on standalone instance but on replicated topology I wonder if it could
have the same symptom.


I've not been able to reproduce the issue in my sandbox environment so I'm not 
sure.  It is also replicated.

-andy



--
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 cluster shutdown sequence

[Thomas Lau]

thanks, sorry that I missed that message.

On Mon, May 4, 2015 at 4:33 PM, David Kupka  wrote:
> On 05/04/2015 07:09 AM, Thomas Lau wrote:
>>
>> Hi All,
>>
>> We got a power maintenance soon, so all servers need to shutdown. Is
>> there have a shutdown / starting up procedure for FreeIPA cluster? We
>> are currently running two node cluster.
>>
>
> Hello,
> as I responded a month ago
> (https://www.redhat.com/archives/freeipa-users/2015-April/msg00016.html)
> there is no special procedure. You just turn the servers off before the
> power outage and then turn them back on.
>
> --
> David Kupka



-- 
Thomas Lau
Director of Infrastructure
Tetrion Capital Limited

Direct: +852-3976-8903
Mobile: +852-9323-9670
Address: 20/F, IFC 1, Central district, Hong Kong

-- 
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 4.1.4 DNS notifications not being sent to slaves

[Petr Spacek]

Hello!

On 2.5.2015 17:12, Nathan Peters wrote:
> The last 3 sentences of my original post refer to me adding the NS records for
> the slave.  Is that what you mean?
> 
> "I have also ensured that the slave hostname and IP are in FreeIPA DNS.  I
> have also added an NS entry pointing to the slave."

Which version of FreeIPA and bind-dyndb-ldap are you using?

I will look into it.

Petr^2 Spacek


> -Original Message- From: Baird, Josh
> Sent: Saturday, May 02, 2015 7:33 AM
> To: 'nat...@nathanpeters.com' ; freeipa-users@redhat.com
> Subject: RE: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to
> slaves
> 
> Is the PowerDNS slave in the NS RRSet for the IPA domain?  Unfortuantely,
> bind-dyndb-ldap does not support 'also-notify' which would allow us to send
> notifies each time a zone update occurs to slave servers that are not in the
> RRSet [1].  To compensate for this in my environment, I had to lower the
> 'refresh' timer on the IPA zone.
> 
> [1] https://fedorahosted.org/bind-dyndb-ldap/ticket/152
> 
> -Original Message-
> From: freeipa-users-boun...@redhat.com
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of nat...@nathanpeters.com
> Sent: Friday, May 1, 2015 8:20 PM
> To: freeipa-users@redhat.com
> Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to 
> slaves
> 
> I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas.
> 
> I also have another host running PowerDNS serving as a slave.
> The FreeIPA servers are setup to allow transfers to the slave by IP.  When
> adding the zone, the slave transfered it properly.
> 
> However, when I update the zone in FreeIPA, although the serial number
> changes, in the /var/log/messages I only see an attempt to transfer to the
> second IPA server, and not the slave.  This is the only log entry :
> 
> May  2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending notifies
> (serial 1430528817) May  2 01:06:57 dc1 named-pkcs11[5897]: client
> 10.178.0.99#29832: received notify for zone 'mydomain.net'
> 
> I have restarted all services using ipactl restart several times.  I have also
> ensured that the slave hostname and IP are in FreeIPA DNS.  I have also added
> an NS entry pointing to the slave.
> 
> According to the FreeIPA manual, once that NS entry is added, any zone updates
> should trigger a notify, but still the only notifications go out to FreeIPA
> servers and nothing else.
> 
> Any idea how to fix this so FreeIPA notifies non IPA servers?  I'm pretty sure
> I've followed all the instructions to the letter on this one...
> 
> 
> -- 
> 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


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

Re: [Freeipa-users] Setup of SRV records for new domains

[Petr Spacek]

On 4.5.2015 10:23, Brian Topping wrote:
> On second view, I think my brain misfiled this. Maybe the records were
> not set up automatically, another DNS domain I thought had the records in
> fact do not.
> 
> As a feature request, it seems like if a domain is added to "Domain
> Realms", it should also get the appropriate records for client
> autodiscovery.

It is actually not necessary to create all the SRV records in all domains.

Client auto-discovery is using the TXT record which is added automatically
and the _kerberos TXT record is like 'redirect'.

The procedure is:
- client client1.sub.example.com. searches for record
_kerberos.sub.example.com TXT
- _kerberos.sub.example.com TXT contains realm name "EXAMPLE.COM"
- now the client knows that all the SRV records are inside example.com. domain
- SRV records from example.com. are used from now on

AFAIK this is very standard Kerberos behavior so it should work for all
standard-compliant clients.

Petr^2 Spacek

> Cheers, Brian
> 
>> On May 4, 2015, at 3:03 PM, Brian Topping 
>> wrote:
>> 
>> I just added a new domain and didn't see the SRV records added for it.
>> There is a TXT record, but none of the SRV records that are in other
>> DNS domains.
>> 
>> After going to the "Realm Domains tab of the "IPA Server"
>> configuration, I see that the new domain was already added there, so I
>> removed it and added it back, hoping that might cause the SRV records
>> to be added, but no luck.
>> 
>> Any ideas what I should check for?
>> 
>> Thanks, Brian

-- 
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 cluster shutdown sequence

[David Kupka]

On 05/04/2015 07:09 AM, Thomas Lau wrote:

Hi All,

We got a power maintenance soon, so all servers need to shutdown. Is
there have a shutdown / starting up procedure for FreeIPA cluster? We
are currently running two node cluster.



Hello,
as I responded a month ago 
(https://www.redhat.com/archives/freeipa-users/2015-April/msg00016.html) 
there is no special procedure. You just turn the servers off before the 
power outage and then turn them back on.


--
David Kupka

--
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] Setup of SRV records for new domains

[Brian Topping]

On second view, I think my brain misfiled this. Maybe the records were not set 
up automatically, another DNS domain I thought had the records in fact do not.

As a feature request, it seems like if a domain is added to "Domain Realms", it 
should also get the appropriate records for client autodiscovery.

Cheers, Brian

> On May 4, 2015, at 3:03 PM, Brian Topping  wrote:
> 
> I just added a new domain and didn't see the SRV records added for it. There 
> is a TXT record, but none of the SRV records that are in other DNS domains.
> 
> After going to the "Realm Domains tab of the "IPA Server" configuration, I 
> see that the new domain was already added there, so I removed it and added it 
> back, hoping that might cause the SRV records to be added, but no luck.
> 
> Any ideas what I should check for?
> 
> Thanks, Brian



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
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] Setup of SRV records for new domains

[Brian Topping]

I just added a new domain and didn't see the SRV records added for it. There is 
a TXT record, but none of the SRV records that are in other DNS domains.

After going to the "Realm Domains tab of the "IPA Server" configuration, I see 
that the new domain was already added there, so I removed it and added it back, 
hoping that might cause the SRV records to be added, but no luck.

Any ideas what I should check for?

Thanks, Brian


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
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