date:20150911

Re: [Freeipa-users] ipa-client-install not creating reverse DNS entries

2015-09-11 Thread Simo Sorce

On Fri, 2015-09-11 at 10:25 -0700, nat...@nathanpeters.com wrote:
> I have been trying to figure this out for a while now but when I join 
> machine to FreeIPA, the installer properly creates forward DNS
> entries,and DNSSSHFP entries, but does not create reverse entries.
> Without the PTR records, kerberos logins are always failing on these
> machines.

I am interested in understanding what fails exactly, stuff should not
depend on reverse resolution can you give me an example of a failure ?

For the PTR creation anyway have you enabled the option to allow setting
PTR records ?
There is a global DNS option (As awell as per-zone setting) called
"Allow PTR Sync" you may want to enable.

-- 
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] ipa-client-install not creating reverse DNS entries

2015-09-11 Thread nathan

I have been trying to figure this out for a while now but when I join a
machine to FreeIPA, the installer properly creates forward DNS entries,
and DNSSSHFP entries, but does not create reverse entries.  Without the
PTR records, kerberos logins are always failing on these machines.

The reverse zones exist, all DNS is managed by FreeIPA, and I am able to
manually add the entries just fine.

Environment :
Servers : CentOS7, FreeIPA 4.1.4
Clients : CentOS 6.5, FreeIPA client 3.0.0-42

I have tried this both with the Internal FreeIPA 'admin' user as the join
user and as another user called 'joinscript' which has the host enrollment
and DNS administrator privileges.

Here is the ipa-client install log:

2015-09-11T16:24:05Z DEBUG /usr/sbin/ipa-client-install was invoked with
options: {'domain': None, 'force': False, 'krb5_offline_passwords': True,
'primary': False, 'mkhomedir': True, 'create_sshfp': True, 'conf_sshd':
True, 'conf_ntp': True, 'on_master': False, 'ntp_server': None, 'server':
None, 'no_nisdomain': False, 'principal': 'joinscript', 'hostname':
'ipaclient.ipadomain.net', 'no_ac': False, 'unattended': True, 'sssd':
True, 'trust_sshfp': False, 'realm_name': None, 'dns_updates': True,
'conf_sudo': True, 'conf_ssh': True, 'force_join': True, 'ca_cert_file':
None, 'nisdomain': None, 'prompt_password': False, 'permit': False,
'debug': False, 'preserve_sssd': False, 'uninstall': False}
2015-09-11T16:24:05Z DEBUG missing options might be asked for
interactively later
2015-09-11T16:24:05Z DEBUG Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2015-09-11T16:24:05Z DEBUG Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
2015-09-11T16:24:05Z DEBUG [IPA Discovery]
2015-09-11T16:24:05Z DEBUG Starting IPA discovery with domain=None,
servers=None, hostname=ipaclient.ipadomain.net
2015-09-11T16:24:05Z DEBUG Start searching for LDAP SRV record in
"ipadomain.net" (domain of the hostname) and its sub-domains
2015-09-11T16:24:05Z DEBUG Search DNS for SRV record of
_ldap._tcp.ipadomain.net.
2015-09-11T16:24:05Z DEBUG DNS record found:
DNSResult::name:_ldap._tcp.ipadomain.net.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:dc1.ipadomain.net.}
2015-09-11T16:24:05Z DEBUG DNS record found:
DNSResult::name:_ldap._tcp.ipadomain.net.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:dc2.ipadomain.net.}
2015-09-11T16:24:05Z DEBUG [Kerberos realm search]
2015-09-11T16:24:05Z DEBUG Search DNS for TXT record of
_kerberos.ipadomain.net.
2015-09-11T16:24:05Z DEBUG DNS record found:
DNSResult::name:_kerberos.ipadomain.net.,type:16,class:1,rdata={data:ipadomain.net}
2015-09-11T16:24:05Z DEBUG Search DNS for SRV record of
_kerberos._udp.ipadomain.net.
2015-09-11T16:24:05Z DEBUG DNS record found:
DNSResult::name:_kerberos._udp.ipadomain.net.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:dc2.ipadomain.net.}
2015-09-11T16:24:05Z DEBUG DNS record found:
DNSResult::name:_kerberos._udp.ipadomain.net.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:dc1.ipadomain.net.}
2015-09-11T16:24:05Z DEBUG [LDAP server check]
2015-09-11T16:24:05Z DEBUG Verifying that dc1.ipadomain.net (realm
ipadomain.net) is an IPA server
2015-09-11T16:24:05Z DEBUG Init LDAP connection with:
ldap://dc1.ipadomain.net:389
2015-09-11T16:24:05Z DEBUG Search LDAP server for IPA base DN
2015-09-11T16:24:05Z DEBUG Check if naming context 'dc=ipadomain,dc=net'
is for IPA
2015-09-11T16:24:05Z DEBUG Naming context 'dc=ipadomain,dc=net' is a valid
IPA context
2015-09-11T16:24:05Z DEBUG Search for (objectClass=krbRealmContainer) in
dc=ipadomain,dc=net (sub)
2015-09-11T16:24:05Z DEBUG Found:
cn=ipadomain.net,cn=kerberos,dc=ipadomain,dc=net
2015-09-11T16:24:05Z DEBUG Discovery result: Success;
server=dc1.ipadomain.net, domain=ipadomain.net,
kdc=dc2.ipadomain.net,dc1.ipadomain.net, basedn=dc=ipadomain,dc=net
2015-09-11T16:24:05Z DEBUG Validated servers: dc1.ipadomain.net
2015-09-11T16:24:05Z DEBUG will use discovered domain: ipadomain.net
2015-09-11T16:24:05Z DEBUG Start searching for LDAP SRV record in
"ipadomain.net" (Validating DNS Discovery) and its sub-domains
2015-09-11T16:24:05Z DEBUG Search DNS for SRV record of
_ldap._tcp.ipadomain.net.
2015-09-11T16:24:05Z DEBUG DNS record found:
DNSResult::name:_ldap._tcp.ipadomain.net.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:dc2.ipadomain.net.}
2015-09-11T16:24:05Z DEBUG DNS record found:
DNSResult::name:_ldap._tcp.ipadomain.net.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:dc1.ipadomain.net.}
2015-09-11T16:24:05Z DEBUG DNS validated, enabling discovery
2015-09-11T16:24:05Z DEBUG will use discovered server: dc1.ipadomain.net
2015-09-11T16:24:05Z INFO Discovery was successful!
2015-09-11T16:24:05Z DEBUG will use discovered realm: ipadomain.net
2015-09-11T16:24:05Z DEBUG will use discovered basedn: dc=ipadomain,dc=net
2015-09-11T16:24:05Z INFO Hostname: ipaclient.ipadomain.net
2015-09-11T16:24:05Z DEBUG

[Freeipa-users] [work-around] sss_ssh_knownhostsproxy problem with sparkleshare due to setlocale()

2015-09-11 Thread Karl Forner

Hi,

I kind of fixed my problem, but I share it there in case it can help others.

I had problems with sparkleshare on my freeIPA-enrolled workstation, e.g. I
got
error messages like this:

19:04:52 | Cmd | QB_resources | git ls-remote --heads --exit-code
"ssh://xxxl@/secure/sparkleshare/resources" master
19:04:52 | Git | projects | (Wed Sep  9 19:04:52:432246 2015)
[/usr/bin/sss_ssh_knownhostsproxy] [main] (0x0020): set_locale() failed
(5): Input/output error

I went to see the source code of sss_ssh_knownhostsproxy, and it seems that
the problem comes from these lines:
   c = setlocale(LC_ALL, "");
if (c == NULL) {
return EIO;
}

According to "man setlocale()", this is perfectly good:

>On startup of the main program, the portable "C" locale is
selected as default.  A program may be made portable to all locales by
calling:
>   setlocale(LC_ALL, "");
 and
> For glibc, first (regardless of
 >  category), the environment variable LC_ALL is inspected, next the
environment variable with the same name as the  category  (LC_COLLATE,
LC_CTYPE,  LC_MESSAGES,  LC_MONETARY,  LC_NUMERIC,
 >  LC_TIME) and finally the environment variable LANG.  The first
existing environment variable is used.  If its value is not a valid locale
specification, the locale is unchanged, and setlo‐
 >  cale() returns NULL.

In my case, apparently setlocate() returns NULL. I could not reproduce this
setlocale() call by myself, event trying to use the environment of the
sparkleshare process (which by the way is a mono program).

But I noticed that running sparkleshare as followed fixed the problem:
   LC_ALL="en_US.UTF-8" mono "/usr/lib/sparkleshare/SparkleShare.exe"

So I just edited my /etc/default/locale to permanently fix my problem.
Nonetheless, I'd be curious the understand why the setlocale() call fails
when sss_ssh_knownhostsproxy is called via git via sparkleshare (via mono).

Regards,
Karl Forner
-- 
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] New Host and IP Address

2015-09-11 Thread Günther J . Niederwimmer

Hello,

System CentOs 7 FreeIPA 4.1,

I like to add a new Host with a Service like imap/imap.example.com

The imap.example.com exist in the zone file with a CNAME Record.

I can't found the correct Doc for my Problem ;-)


the second Problem is, is it possible to add a IPv6 Address to the Host and 
Certificates?

Thanks's for a answer, 
-- 
mit freundlichen Grüssen / best regards,

 Günther J. Niederwimmer

-- 
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] [work-around] sss_ssh_knownhostsproxy problem with sparkleshare due to setlocale()

2015-09-11 Thread Alexander Bokovoy

On Fri, 11 Sep 2015, Karl Forner wrote:

Hi,

I kind of fixed my problem, but I share it there in case it can help others.

I had problems with sparkleshare on my freeIPA-enrolled workstation, e.g. I
got
error messages like this:

19:04:52 | Cmd | QB_resources | git ls-remote --heads --exit-code
"ssh://xxxl@/secure/sparkleshare/resources" master
19:04:52 | Git | projects | (Wed Sep  9 19:04:52:432246 2015)
[/usr/bin/sss_ssh_knownhostsproxy] [main] (0x0020): set_locale() failed
(5): Input/output error

I went to see the source code of sss_ssh_knownhostsproxy, and it seems that
the problem comes from these lines:
  c = setlocale(LC_ALL, "");
   if (c == NULL) {
   return EIO;
   }

According to "man setlocale()", this is perfectly good:

   On startup of the main program, the portable "C" locale is

selected as default.  A program may be made portable to all locales by
calling:

  setlocale(LC_ALL, "");

and

For glibc, first (regardless of

>  category), the environment variable LC_ALL is inspected, next the
environment variable with the same name as the  category  (LC_COLLATE,
LC_CTYPE,  LC_MESSAGES,  LC_MONETARY,  LC_NUMERIC,
>  LC_TIME) and finally the environment variable LANG.  The first
existing environment variable is used.  If its value is not a valid locale
specification, the locale is unchanged, and setlo‐
>  cale() returns NULL.

In my case, apparently setlocate() returns NULL. I could not reproduce this
setlocale() call by myself, event trying to use the environment of the
sparkleshare process (which by the way is a mono program).

But I noticed that running sparkleshare as followed fixed the problem:
  LC_ALL="en_US.UTF-8" mono "/usr/lib/sparkleshare/SparkleShare.exe"

So I just edited my /etc/default/locale to permanently fix my problem.
Nonetheless, I'd be curious the understand why the setlocale() call fails
when sss_ssh_knownhostsproxy is called via git via sparkleshare (via mono).

Thanks for the report. Could you please file a bug against sssd to have
this fixed?

There are multiple cases when your own locale is different from the
remote environment and in cloud images you might not even have
additional locale information available, so when SSH is configured to
pass LC_* variables (like in Fedora or RHEL), they are forced in the
remote shell and the setlocale() result is often NULL. I'm stumbling
with this all the time.
--
/ Alexander Bokovoy

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

Re: [Freeipa-users] New Host and IP Address

2015-09-11 Thread Alexander Bokovoy


On Fri, 11 Sep 2015, Günther J. Niederwimmer wrote:

Hello,

System CentOs 7 FreeIPA 4.1,

I like to add a new Host with a Service like imap/imap.example.com

The imap.example.com exist in the zone file with a CNAME Record.

I can't found the correct Doc for my Problem ;-)

ipa help host
ipa help service

and in general 'ipa help ' or 'ipa help ' where command
is something reported by 'ipa help ' are very helpful if you
don't want to go and read the actual user's guide (which is very
comprehensive and has specific sections on host and service operations).

A CNAME-based hostname will not work for GSSAPI authentication so your
service bsaed on CNAME couldn't get Kerberos keys properly. You need to
create both A host entry and then service on that host to make sure they
are properly authenticating over GSSAPI/Kerberos. To allow issuing
certificates for services with subjectAltName to CNAME, make sure an A
host manages a CNAME host in IPA (see 'ipa host-*' related commands).


the second Problem is, is it possible to add a IPv6 Address to the Host and
Certificates?

While IP addresses could be added to certificates, we don't allow it as
it is not recommended practice, thus our current validation rules
prevent it. In short, you cannot currently set up a certificate request
that includes IPv4/IPv6 addresses to certificate's subjectAltName.

A question of IPv4/IPv6 addresses for hosts is orthogonal to IPA itself.
Whatever you use for DNS, should be able to handle A/ entries
(including IPA DNS).

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] [work-around] sss_ssh_knownhostsproxy problem with sparkleshare due to setlocale()

2015-09-11 Thread Karl Forner

done:
Ticket #2785 
On Fri, Sep 11, 2015 at 10:17 AM, Alexander Bokovoy 
wrote:

> On Fri, 11 Sep 2015, Karl Forner wrote:
>
>> Hi,
>>
>> I kind of fixed my problem, but I share it there in case it can help
>> others.
>>
>> I had problems with sparkleshare on my freeIPA-enrolled workstation, e.g.
>> I
>> got
>> error messages like this:
>>
>> 19:04:52 | Cmd | QB_resources | git ls-remote --heads --exit-code
>> "ssh://xxxl@/secure/sparkleshare/resources" master
>> 19:04:52 | Git | projects | (Wed Sep  9 19:04:52:432246 2015)
>> [/usr/bin/sss_ssh_knownhostsproxy] [main] (0x0020): set_locale() failed
>> (5): Input/output error
>>
>> I went to see the source code of sss_ssh_knownhostsproxy, and it seems
>> that
>> the problem comes from these lines:
>>   c = setlocale(LC_ALL, "");
>>if (c == NULL) {
>>return EIO;
>>}
>>
>> According to "man setlocale()", this is perfectly good:
>>
>>On startup of the main program, the portable "C" locale is
>>>
>> selected as default.  A program may be made portable to all locales by
>> calling:
>>
>>>   setlocale(LC_ALL, "");
>>>
>> and
>>
>>> For glibc, first (regardless of
>>>
>> >  category), the environment variable LC_ALL is inspected, next the
>> environment variable with the same name as the  category  (LC_COLLATE,
>> LC_CTYPE,  LC_MESSAGES,  LC_MONETARY,  LC_NUMERIC,
>> >  LC_TIME) and finally the environment variable LANG.  The first
>> existing environment variable is used.  If its value is not a valid locale
>> specification, the locale is unchanged, and setlo‐
>> >  cale() returns NULL.
>>
>> In my case, apparently setlocate() returns NULL. I could not reproduce
>> this
>> setlocale() call by myself, event trying to use the environment of the
>> sparkleshare process (which by the way is a mono program).
>>
>> But I noticed that running sparkleshare as followed fixed the problem:
>>   LC_ALL="en_US.UTF-8" mono "/usr/lib/sparkleshare/SparkleShare.exe"
>>
>> So I just edited my /etc/default/locale to permanently fix my problem.
>> Nonetheless, I'd be curious the understand why the setlocale() call fails
>> when sss_ssh_knownhostsproxy is called via git via sparkleshare (via
>> mono).
>>
> Thanks for the report. Could you please file a bug against sssd to have
> this fixed?
>
> There are multiple cases when your own locale is different from the
> remote environment and in cloud images you might not even have
> additional locale information available, so when SSH is configured to
> pass LC_* variables (like in Fedora or RHEL), they are forced in the
> remote shell and the setlocale() result is often NULL. I'm stumbling
> with this all the time.
> --
> / Alexander Bokovoy
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Using SSH from Active Directory machines for FreeIPA clients with kerberos tickets

2015-09-11 Thread Alexander Bokovoy


On Fri, 11 Sep 2015, Morgan Marodin wrote:

Hi everyone.

I've seen these guides:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ssh.html
https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-ssh.html
https://www.dalemacartney.com/2013/08/30/single-sign-on-sso-with-secure-shell-ssh/

But I've not been able to access via ssh to a freeipa client with kerberos
tickets.
I've also tried to install MIT kerberos to my windows 8.1, but doesn't
works too.

This is not required.

What Windows 8.1 version you have? Is it a Pro edition (the other
editions don't join AD)?


The target freeipa client is a RHEL 6.7 like distribution.

Naturally trying with AD username (name.surn...@mydomain.com) and password
is ok.

Do you have any suggestions for this problem?

Enable DEBUG3 level logging in sshd_config for SSH server, attempt to
login from Windows client and show the logs around 'userok' in the
resulting debug output.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] AD Trust Issues

2015-09-11 Thread Alexander Bokovoy


On Fri, 11 Sep 2015, Matt Wells wrote:

I've been working on an AD trust with our freeipa servers but have run into
some of the same issues others have had.
It's well documented here however I feel I've mitigated these -
https://bugzilla.redhat.com/show_bug.cgi?id=1219832

Freeipa Servers are Fedora 22 / freeipa-server-4.2.0
The Samba version i'm on is well past the patched version.  It seems the
patch is in samba-4.2.1-7.fc22 and I'm on samba-4.2.3-0 (assuming the patch
is in this version).

I run
# echo Password123 | ipa trust-add --type=ad ad.example.com --trust-secret
ipa: ERROR: CIFS server configuration does not allow access to \\pipe\lsarpc

This was looking like a partial fix. The full fix is in Fedora 23 with
FreeIPA 4.2.1 release (we didn't yet officially announced it).

We were all busy at FreeIPA/SSSD gathering in Brno this week so there
wasn't really time to do Fedora 22 backport of the fixes yet.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] ntpd frequency error xxx PPM exceeds tolerance 500 PPM

2015-09-11 Thread Prasun Gera

Has this got anything to do with ipa ? The messages started only recently,
which makes me think that it's not a hardware issue. There were only two
notable changes to this system recently. The hdd had to be replaced, and a
replica was set up. Could either have any part to play ?

On Thu, Sep 10, 2015 at 6:03 AM, Prasun Gera  wrote:

> The hardware is not very old (ivybridge). The entries appear every few
> minutes in the log. The /etc/ntp.conf has not been modified manually. It
> lists 3 servers - 0.rhel.pool.ntp.org, 1 and 2. At the end, there are
> also a couple of additional local servers with the comment added by
> /sbin/dhclient-script. The replica on the same network with an identical
> ntp.conf file doesn't have these messages in the current log. However, if I
> go back to a week, I see similar messages there too.  The ping to public
> ntp servers varies from to a few ms to ~50 ms. The ping to local servers is
> under 1 ms. I followed steps from the first link (ntpd -qg), and the
> messages have stopped for now, but I suspect that they will reappear later.
> That's what happened last time I tried that solution. This is the output
> from ntpq -pn on the master:
>
>  remote   refid  st t when poll reach   delay   offset
>  jitter
>
> ==
> +38.229.71.1 204.123.2.5  2 u   39   64  377   44.300  -1311.8
> 7.668
> +64.6.144.6  128.252.19.1 2 u   25   64  377   38.184  -1327.6
>  12.615
> -129.250.35.251  200.98.196.212   2 u   30   64  377   14.649  -1318.8
> 7.079
>  127.127.1.0 .LOCL.  10 l-   6400.0000.000
> 0.000
> *localnetip1  localnetref1  2 u   55   64  3770.349  -1316.0   8.264
> -localnetip2  localnetref23 u   64   64  3770.459  -1309.6  10.516
>
>
> On Thu, Sep 10, 2015 at 5:27 AM, Andrew Holway 
> wrote:
>
>> If could be the server is trying to access the time server over a heavily
>> congested network which could cause these types of problems.
>>
>>
>> How old is the hardware?
>> How often to these entries appear in the log?
>> What is the ping / traceroute to the time server you are using?
>> Are there any other machines on the same local network that are using
>> this timeserver? Do they have problems?
>>
>>
>>
>>
>> On 10 September 2015 at 14:18, Prasun Gera  wrote:
>>
>>> So I did a bit of googling and tinker panic 0 only makes sense for
>>> virtual machines. Is there any way to confirm if it is indeed a hardware
>>> issue ?
>>>
>>> On Thu, Sep 10, 2015 at 5:16 AM, Andrew Holway 
>>> wrote:
>>>
 Thats odd. You would normally not need it on bare metal. It could be
 broken hardware.

 On 10 September 2015 at 14:05, Prasun Gera 
 wrote:

> Thanks. I'm not virtualizing though. Should I still add it ?
>
> On Thu, Sep 10, 2015 at 5:02 AM, Andrew Holway <
> andrew.hol...@gmail.com> wrote:
>
>> Hi,
>>
>> I assume you are virtualising.
>>
>> Try adding "tinker panic 0" to /etc/ntp.conf.
>>
>> It should make it tolerant to heavily drifting virtual clocks.
>>
>> Cheers,
>>
>> Andrew
>>
>> On 10 September 2015 at 13:46, Prasun Gera 
>> wrote:
>>
>>> OS: RHEL 7.1 w IDM
>>>
>>> I'm seeing these messages in my master's log messages. I don't know
>>> if it's related, but I think I started seeing them after I set up a
>>> replica. Everything seems to be working fine, but I'm worried that 
>>> things
>>> will break if delta grows beyond a point. I tried steps in
>>> https://access.redhat.com/solutions/35640, but it didn't really
>>> help. The messages still appear regularly in the log.
>>>
>>> --
>>> 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

[Freeipa-users] Search 'hosts'

2015-09-11 Thread Craig White

ipa-server-4.1.0-18.el7_1.4.x86_64

Maybe I was spoiled but from the web ui, I can't seem to search for hosts or 
DNS names - all searches seem to return nothing at all

User searches work (thankfully)

Previous version 3.0.0 from RHEL6 I could just put in ipa and get the hosts 
listed that had ipa in them.

Is it just me?

Craig White
System Administrator
O 623-201-8179   M 602-377-9752

[cid:image001.png@01CF86FE.42D51630]

SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032

-- 
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] vsftpd PAM setup problem

2015-09-11 Thread jcnt

Hi All,

I am using RHEL 7 with ipa server and vsftpd - no modifications to installed 
packages whatsoever.
Local users (listed in /etc/passwd) can login using ftp client but ipa defined 
users get login denied. Here is the snippet from /var/log/audit/audit.log
type=USER_AUTH msg=audit(1442012213.988:24095): pid=27280 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 
msg='op=PAM:authentication grantors=? acct="admin" exe="/usr/sbin/vsftpd" 
hostname=:::192.168.1.11 addr=:::192.168.1.11 terminal=ftp res=failed'

for local account:
type=USER_AUTH msg=audit(1442012143.221:24056): pid=27173 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 
msg='op=PAM:authentication grantors=pam_listfile,pam_shells,pam_unix 
acct="jcnt" exe="/usr/sbin/vsftpd" hostname=:::192.168.1.11 
addr=:::192.168.1.11 terminal=ftp res=success'

Grantors value is missing when ipa defined user is processed ...

admin user uses default HBAC - all hosts all services.

Identical behavior on a test system running CentOS 7.

I found similar subject thread 
https://www.redhat.com/archives/freeipa-users/2014-October/msg00479.html but 
seems not applicable, I haven't touched /tmp permissions/ownership.
--
Josh.

-- 
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-client-install not creating reverse DNS entries

2015-09-11 Thread Nathan Peters



On 9/11/2015 10:32 AM, Simo Sorce wrote:

On Fri, 2015-09-11 at 10:25 -0700, nat...@nathanpeters.com wrote:

I have been trying to figure this out for a while now but when I join
machine to FreeIPA, the installer properly creates forward DNS
entries,and DNSSSHFP entries, but does not create reverse entries.
Without the PTR records, kerberos logins are always failing on these
machines.

I am interested in understanding what fails exactly, stuff should not
depend on reverse resolution can you give me an example of a failure ?

For the PTR creation anyway have you enabled the option to allow setting
PTR records ?
There is a global DNS option (As awell as per-zone setting) called
"Allow PTR Sync" you may want to enable.



When we attempt to login using kerberos on a machine that has no reverse 
DNS entry defined, we are instead prompted with a password prompt.  The 
password authentication still works but the ticket does not.


From what I read, the Allow PTR Sync option is only used in conjunction 
with DNS IP address changes and does not apply to the initial join of 
the domain.


Is the joining process supposed to create reverse DNS entries for the 
clients or just forward entries and SSHFP entries?


--
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] Migrating from iDM/FreeIPA RHEL 6.5 to 7.1 - CA Server Master

2015-09-11 Thread Craig White

-Original Message-
From: Martin Kosek [mailto:mko...@redhat.com] 
Sent: Friday, September 11, 2015 8:46 AM
To: Rob Crittenden; Craig White; freeipa-users@redhat.com; Jan Cholasta; Jan 
Cholasta
Subject: Re: [Freeipa-users] Migrating from iDM/FreeIPA RHEL 6.5 to 7.1 - CA 
Server Master

On 09/11/2015 03:29 PM, Rob Crittenden wrote:
> Craig White wrote:
>> Following instructions from here...
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linu
>> x/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrat
>> ing-ipa-proc.html
>>
>>  
>>
>> RHEL6 server
>>
>> # rpm -qa ipa-server
>>
>> ipa-server-3.0.0-42.el6.x86_64
>>
>>  
>>
>> RHEL7 server
>>
>> # rpm -q ipa-server
>>
>> ipa-server-4.1.0-18.el7_1.4.x86_64
>>
>>  
>>
>> I am down to the part where I am trying to make the new RHEL7 server 
>> the master CA server
>>
>>  
>>
>> On the RHEL6 system, I
>>
>> # getcert list -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca"
>>
>> Number of certificates and requests being tracked: 8.
>>
>> Request ID '20141022190721':
>>
>> status: MONITORING
>>
>> stuck: no
>>
>> key pair storage:
>> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert
>> cert-pki-ca',token='NSS Certificate DB',pin=OBSCURED
>>
>> certificate:
>> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert
>> cert-pki-ca',token='NSS Certificate DB'
>>
>> CA: dogtag-ipa-renew-agent
>>
>> issuer: CN=Certificate Authority,O=STT.LOCAL
>>
>> subject: CN=CA Subsystem,O=STT.LOCAL
>>
>> expires: 2016-10-11 19:06:36 UTC
>>
>> key usage:
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>
>> eku: id-kp-serverAuth,id-kp-clientAuth
>>
>> pre-save command:
>>
>> post-save command:
>>
>> track: yes
>>
>> auto-renew: yes
>>
>>  
>>
>> and the 'post-save' command is empty, doesn't track the page. Should 
>> I just ignore? I note that the output from this (save for different 
>> file path on RHEL6) indicates that the original RHEL6 is still CA 
>> Master
> 
> There was a bug in certmonger where the pre/post save commands 
> wouldn't display. I believe this was fixed, see if there is an updated 
> package available. Otherwise you'd have to poke around in the tracking 
> files in /var/lib/certmonger.

I think Rob meant this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1181022

It should be fixed in certmonger-0.75.14-3.el7. CCing Jan in case he knows 
about other similar fixes.

> 
>> The CRL generation master can be determined by looking at CS.cfg on each CA:
>>
>> # grep ca.crl.MasterCRL.enableCRLUpdates 
>> /etc/pki/pki-tomcat/ca/CS.cfg
>>
>> ca.crl.MasterCRL.enableCRLUpdates=true
>>
>>  
>>
>>  
>>
>> Also, when I set up the second new IPA master, do I also make it a CA?
> 
> I'd say yes. You always at at least 2 masters with a CA.
> 
> rob
> 

Indeed - updating the RHEL6 system to current (certmonger) remedied the issue 
and I was able to proceed.

Seems I am complete - at least to the point of shutting down the old IPA 
servers.

Thanks for the great support Rob/Martin and of course everyone in the FreeIPA 
group - you guys are awesome!

Craig

-- 
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] Logging?

2015-09-11 Thread Jakub Hrozek

On Thu, Sep 10, 2015 at 08:05:16AM -0700, Janelle wrote:
> On 9/10/15 7:55 AM, Martin Kosek wrote:
> >On 09/09/2015 09:50 PM, Janelle wrote:
> >>Hello,
> >>
> >>I was wondering if anyone has played with thee extended logging of IPA and
> >>specifically SSSD and the kibana dashboards they put together.
> >>https://www.freeipa.org/page/Centralized_Logging
> >>
> >>I can't seem to get "clients" to send the login info
> >>(https://www.freeipa.org/images/6/65/Rek-user-logins.png) , even though I 
> >>see
> >>the data in the logs, and was wondering if anyone has any tips?
> >>
> >>Thank you
> >>~Janelle
> >Thanks for feedback, I am CCing Peter Schiffer and Jakub Hrozek who were
> >involved more in the client parts.
> >
> >What did you run for configuring the client? ipa-log-config from
> >
> >https://github.com/pschiffe/ipa-log-config
> >
> >?
> Hi Martin,
> 
> Yes, I did run the log config tool. It works flawlessly on the IPA servers,
> but although it claims it sets everything up on clients, I am seeing no
> actual data, even though, there is data in the logs themselves.. So I am
> busy trying to debug where rsyslog is missing something. I am more of a
> syslog-ng  person, so I am having to learn all the bits and pieces of
> rsyslog, and perhaps I am missing something.
> 
> To further help -- I have tried 2 methods of a client. One with a client
> that was "enrolled" via standard ipa-client-install, and another LDAP-only
> client, still using SSSD but only configured with LDAP settings for Auth.

I would suggest to debug step by step -- are the sssd debug logs being
generated? Are they being collected by rsyslog? etc..

-- 
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 entry not found by sssd in the cache db

2015-09-11 Thread Pavel Březina


On 09/09/2015 09:31 PM, Molnár Domokos wrote:

I have a working IPA server and a working client config on an OpenSuse
13.2 with the following versions:
nappali:~ # rpm -qa |grep sssd
sssd-tools-1.12.2-3.4.1.i586
sssd-krb5-1.12.2-3.4.1.i586
python-sssd-config-1.12.2-3.4.1.i586
sssd-ipa-1.12.2-3.4.1.i586
sssd-1.12.2-3.4.1.i586
sssd-dbus-1.12.2-3.4.1.i586
sssd-krb5-common-1.12.2-3.4.1.i586
sssd-ldap-1.12.2-3.4.1.i586
sssd is confihured for nss, pam, sudo
There is a test sudo rule defined in the ipa server, which applies to
user "doma".  However when the user tries to use sudo the rule does not
work.
doma@nappali:/home/doma> sudo ls
doma's password:
doma is not allowed to run sudo on nappali.  This incident will be reported.
The corresponding log in the sssd_sudo.log is this:
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting default options for [doma] from []
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [doma@szilva]
(Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
(Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(name=defaults)))]
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting rules for [doma] from []
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [doma@szilva]
(Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
(Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
(Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv] (0x0200): Client
disconnected!
This seems perfectly OK with one exception. The query against the sysdb
does not find the entry. This is strange because the entry is there.
Log in sssd.log:
(Wed Sep  2 08:52:13 2015) [sssd] [sysdb_domain_init_internal] (0x0200):
DB File for szilva: /var/lib/sss/db/cache_szilva.ldb
So we know that the sysdb is /var/lib/sss/db/cache_szilva.ldb
Running the exact same query seen above in the sssd_sudo.log against the
db returns:
ldbsearch -H /var/lib/sss/db/cache_szilva.ldb
"(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))"
asq: Unable to register control with rootdse!
# record 1
dn: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
cn: Doma_ls
dataExpireTimestamp: 1441830262
entryUSN: 20521
name: Doma_ls
objectClass: sudoRule
originalDN: cn=Doma_ls,ou=sudoers,dc=szilva
sudoCommand: ls
sudoHost: nappali.szilva
sudoRunAsGroup: ALL
sudoRunAsUser: ALL
sudoUser: doma
distinguishedName: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
# returned 1 records
# 1 entries
# 0 referrals
This confirms that the entry is indeed there in the db. Why is it found
with ldbsearch and why does sssd_sudo not find it?
I am pretty much stuck with this one. Anyone has an idea?



Hi,
this is strange. Can you provide the logs with debug level set to 0x3ff0 
please? Can you also send it as an attachment? Thanks!


--
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 entry not found by sssd in the cache db

2015-09-11 Thread Molnár Domokos

 
"Pavel Březina"  írta:
>On 09/09/2015 09:31 PM, Molnár Domokos wrote:
>> I have a working IPA server and a working client config on an OpenSuse
>> 13.2 with the following versions:
>> nappali:~ # rpm -qa |grep sssd
>> sssd-tools-1.12.2-3.4.1.i586
>> sssd-krb5-1.12.2-3.4.1.i586
>> python-sssd-config-1.12.2-3.4.1.i586
>> sssd-ipa-1.12.2-3.4.1.i586
>> sssd-1.12.2-3.4.1.i586
>> sssd-dbus-1.12.2-3.4.1.i586
>> sssd-krb5-common-1.12.2-3.4.1.i586
>> sssd-ldap-1.12.2-3.4.1.i586
>> sssd is confihured for nss, pam, sudo
>> There is a test sudo rule defined in the ipa server, which applies to
>> user "doma".  However when the user tries to use sudo the rule does not
>> work.
>> doma@nappali:/home/doma> sudo ls
>> domas password:
>> doma is not allowed to run sudo on nappali.  This incident will be reported.
>> The corresponding log in the sssd_sudo.log is this:
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
>> Received client version [1].
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
>> Offered version [1].
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>> (0x0200): name doma matched without domain, user is doma
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>> (0x0200): name doma matched without domain, user is doma
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
>> (0x0200): Requesting default options for [doma] from []
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
>> Requesting info about [doma@szilva]
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>> [(&(objectClass=sudoRule)(|(name=defaults)))]
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>> (0x0200): name doma matched without domain, user is doma
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>> (0x0200): name doma matched without domain, user is doma
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
>> (0x0200): Requesting rules for [doma] from []
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
>> Requesting info about [doma@szilva]
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
>> (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
>> (Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv] (0x0200): Client
>> disconnected!
>> This seems perfectly OK with one exception. The query against the sysdb
>> does not find the entry. This is strange because the entry is there.
>> Log in sssd.log:
>> (Wed Sep  2 08:52:13 2015) [sssd] [sysdb_domain_init_internal] (0x0200):
>> DB File for szilva: /var/lib/sss/db/cache_szilva.ldb
>> So we know that the sysdb is /var/lib/sss/db/cache_szilva.ldb
>> Running the exact same query seen above in the sssd_sudo.log against the
>> db returns:
>> ldbsearch -H /var/lib/sss/db/cache_szilva.ldb
>> "(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))"
>> asq: Unable to register control with rootdse!
>> # record 1
>> dn: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
>> cn: Doma_ls
>> dataExpireTimestamp: 1441830262
>> entryUSN: 20521
>> name: Doma_ls
>> objectClass: sudoRule
>> originalDN: cn=Doma_ls,ou=sudoers,dc=szilva
>> sudoCommand: ls
>> sudoHost: nappali.szilva
>> sudoRunAsGroup: ALL
>> sudoRunAsUser: ALL
>> sudoUser: doma
>> distinguishedName: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
>> # returned 1 records
>> # 1 entries
>> # 0 referrals
>> This confirms that the entry is indeed there in the db. Why is it found
>> with ldbsearch and why does sssd_sudo not find it?
>> I am pretty much stuck with this one. Anyone has an idea?
>>
>>
>Hi,
>this is strange. Can you provide the logs with debug level set to 0x3ff0 
>please? Can you also send it as an attachment? Thanks!
 Sure. Here it is. Now I can see that the rule is returned. The question is why 
the rule does not match. Anyway much better :) (Fri Sep 11 14:19:57 2015) 
[sssd[sudo]] [sudosrv_get_user] (0x0200):

Re: [Freeipa-users] Logging?

2015-09-11 Thread Janelle


On 9/11/15 3:25 AM, Jakub Hrozek wrote:

On Thu, Sep 10, 2015 at 08:05:16AM -0700, Janelle wrote:

On 9/10/15 7:55 AM, Martin Kosek wrote:

On 09/09/2015 09:50 PM, Janelle wrote:

Hello,

I was wondering if anyone has played with thee extended logging of IPA and
specifically SSSD and the kibana dashboards they put together.
https://www.freeipa.org/page/Centralized_Logging

I can't seem to get "clients" to send the login info
(https://www.freeipa.org/images/6/65/Rek-user-logins.png) , even though I see
the data in the logs, and was wondering if anyone has any tips?

Thank you
~Janelle

Thanks for feedback, I am CCing Peter Schiffer and Jakub Hrozek who were
involved more in the client parts.

What did you run for configuring the client? ipa-log-config from

https://github.com/pschiffe/ipa-log-config

?

Hi Martin,

Yes, I did run the log config tool. It works flawlessly on the IPA servers,
but although it claims it sets everything up on clients, I am seeing no
actual data, even though, there is data in the logs themselves.. So I am
busy trying to debug where rsyslog is missing something. I am more of a
syslog-ng  person, so I am having to learn all the bits and pieces of
rsyslog, and perhaps I am missing something.

To further help -- I have tried 2 methods of a client. One with a client
that was "enrolled" via standard ipa-client-install, and another LDAP-only
client, still using SSSD but only configured with LDAP settings for Auth.

I would suggest to debug step by step -- are the sssd debug logs being
generated? Are they being collected by rsyslog? etc..
Ok. Thank you. I had stated that the logs are indeed being populated 
correctly.


I guess it is something with the rsyslog config being set by the tool. I 
will try and debug that. The odd thing is, the settings are the same on 
the IPA server, and it logs correct, but not on clients. Oh well, back 
to the drawing board.


~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] Migrating from iDM/FreeIPA RHEL 6.5 to 7.1 - CA Server Master

2015-09-11 Thread Martin Kosek

On 09/11/2015 03:29 PM, Rob Crittenden wrote:
> Craig White wrote:
>> Following instructions from here…
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html
>>
>>  
>>
>> RHEL6 server
>>
>> # rpm -qa ipa-server
>>
>> ipa-server-3.0.0-42.el6.x86_64
>>
>>  
>>
>> RHEL7 server
>>
>> # rpm -q ipa-server
>>
>> ipa-server-4.1.0-18.el7_1.4.x86_64
>>
>>  
>>
>> I am down to the part where I am trying to make the new RHEL7 server the
>> master CA server
>>
>>  
>>
>> On the RHEL6 system, I
>>
>> # getcert list -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca"
>>
>> Number of certificates and requests being tracked: 8.
>>
>> Request ID '20141022190721':
>>
>> status: MONITORING
>>
>> stuck: no
>>
>> key pair storage:
>> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert
>> cert-pki-ca',token='NSS Certificate DB',pin=OBSCURED
>>
>> certificate:
>> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert
>> cert-pki-ca',token='NSS Certificate DB'
>>
>> CA: dogtag-ipa-renew-agent
>>
>> issuer: CN=Certificate Authority,O=STT.LOCAL
>>
>> subject: CN=CA Subsystem,O=STT.LOCAL
>>
>> expires: 2016-10-11 19:06:36 UTC
>>
>> key usage:
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>
>> eku: id-kp-serverAuth,id-kp-clientAuth
>>
>> pre-save command:
>>
>> post-save command:
>>
>> track: yes
>>
>> auto-renew: yes
>>
>>  
>>
>> and the ‘post-save’ command is empty, doesn’t track the page. Should I
>> just ignore? I note that the output from this (save for different file
>> path on RHEL6) indicates that the original RHEL6 is still CA Master
> 
> There was a bug in certmonger where the pre/post save commands wouldn't
> display. I believe this was fixed, see if there is an updated package
> available. Otherwise you'd have to poke around in the tracking files in
> /var/lib/certmonger.

I think Rob meant this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1181022

It should be fixed in certmonger-0.75.14-3.el7. CCing Jan in case he knows
about other similar fixes.

> 
>> The CRL generation master can be determined by looking at CS.cfg on each CA:
>>
>> # grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg
>>
>> ca.crl.MasterCRL.enableCRLUpdates=true
>>
>>  
>>
>>  
>>
>> Also, when I set up the second new IPA master, do I also make it a CA?
> 
> I'd say yes. You always at at least 2 masters with a CA.
> 
> 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 SSH from Active Directory machines for FreeIPA clients with kerberos tickets

2015-09-11 Thread Morgan Marodin

Hi everyone.

I've seen these guides:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ssh.html
https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-ssh.html
https://www.dalemacartney.com/2013/08/30/single-sign-on-sso-with-secure-shell-ssh/

But I've not been able to access via ssh to a freeipa client with kerberos
tickets.
I've also tried to install MIT kerberos to my windows 8.1, but doesn't
works too.

The target freeipa client is a RHEL 6.7 like distribution.

Naturally trying with AD username (name.surn...@mydomain.com) and password
is ok.

Do you have any suggestions for this problem?

Thanks, bye.
Morgan
-- 
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-client-install not creating reverse DNS entries

[Freeipa-users] ipa-client-install not creating reverse DNS entries

[Freeipa-users] [work-around] sss_ssh_knownhostsproxy problem with sparkleshare due to setlocale()

[Freeipa-users] New Host and IP Address

Re: [Freeipa-users] [work-around] sss_ssh_knownhostsproxy problem with sparkleshare due to setlocale()

Re: [Freeipa-users] New Host and IP Address

Re: [Freeipa-users] [work-around] sss_ssh_knownhostsproxy problem with sparkleshare due to setlocale()

Re: [Freeipa-users] Using SSH from Active Directory machines for FreeIPA clients with kerberos tickets

Re: [Freeipa-users] AD Trust Issues

Re: [Freeipa-users] ntpd frequency error xxx PPM exceeds tolerance 500 PPM

[Freeipa-users] Search 'hosts'

[Freeipa-users] vsftpd PAM setup problem

Re: [Freeipa-users] ipa-client-install not creating reverse DNS entries

Re: [Freeipa-users] Migrating from iDM/FreeIPA RHEL 6.5 to 7.1 - CA Server Master

Re: [Freeipa-users] Logging?

Re: [Freeipa-users] Sudo entry not found by sssd in the cache db

Re: [Freeipa-users] Sudo entry not found by sssd in the cache db

Re: [Freeipa-users] Logging?

Re: [Freeipa-users] Migrating from iDM/FreeIPA RHEL 6.5 to 7.1 - CA Server Master

[Freeipa-users] Using SSH from Active Directory machines for FreeIPA clients with kerberos tickets

20 matches

Site Navigation

Mail list logo

Footer information