[Freeipa-users] freeipa cert validation failed, SEC_ERROR_UNTRUSTED_ISSUER

[mmarodin]

  Hi everyone.

I've a problem with my new freeipa installation,
v4.1.0, over RHEL 7 like distribution.

The installation was ok, but now
I've some problems operating via CLI:
# ipa user-show admin
ipa: ERROR:
cert validation failed for
"CN=srv01.ipa.mydomain.com,O=IPA.MYDOMAIN.COM"
((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked
as not trusted by the user.)
ipa: ERROR: cannot connect to
'https://srv01.ipa.mydomain.com/ipa/json': (SEC_ERROR_UNTRUSTED_ISSUER)
Peer's certificate issuer has been marked as not trusted by the
user.

I've got the same problem connectiong via curl, but after doing
these command for curl now it works, but not for ipa cli
operations:
--
# certutil -A -d /etc/pki/nssdb -n
'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt
# certutil -L -d
/etc/pki/nssdb
Certificate Nickname Trust Attributes

SSL,S/MIME,JAR/XPI
IPA CA CT,C,C
# cp /etc/ipa/ca.crt
/etc/pki/ca-trust/source/anchors/
# update-ca-trust
extract
--

And also this command doesn't work:
#
ipa trust-add --type=ad mydomain.com --admin Administrator
--password
ipa: ERROR: cert validation failed for
"CN=srv01.ipa.mydomain.com,O=IPA.MYDOMAIN.COM"
((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked
as not trusted by the user.)
ipa: ERROR: cannot connect to
'https://srv01.ipa.mydomain.com/ipa/json': (SEC_ERROR_UNTRUSTED_ISSUER)
Peer's certificate issuer has been marked as not trusted by the
user.

So ... what's the problem?

Let me know, thanks.
Morgan 



Connetti gratis il mondo con la nuova indoona:  hai la chat, le chiamate, le 
video chiamate e persino le chiamate di gruppo.
E chiami gratis anche i numeri fissi e mobili nel mondo!
Scarica subito l’app Vai su https://www.indoona.com/

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

Re: [Freeipa-users] SOA Serial changes overnight and is inconsisstent with replica

[Petr Spacek]

On 8.9.2015 14:06, David Dejaeghere wrote:
> @Petr. I understood bind restart caused an increment. But I was unaware
> that this value was not replicated.  If I add a record to a zone the SOA
> serials do get in sync again. But I understand the multimaster setup and
> now I understand where this nightly increment is comming from. It is indeed
> logrotate.

For the record, bind-dyndb-ldap tries to set the SOA serial to unix timestamp
if old SOA serial < current timestamp. If old SOA serial <= current timestamp
then it is incremented by one.

This + different logrorate configuration might explain the difference.


The consequence is that your DNS slaves should be configured to use the same
master all the time and fail over only if the original master is not available.

Petr^2 Spacek

> Kind Regards,
> 
> David
> 
> 2015-09-08 13:16 GMT+02:00 Petr Spacek :
> 
>> On 8.9.2015 13:06, Martin Basti wrote:
>>>
>>>
>>> On 09/07/2015 03:00 PM, David Dejaeghere wrote:
 Hello,

 I noticed on the couple of installs that I am running that my zones have
 different soa serial values on both master and replica.  I also noticed
>> that
 this value is changing without adding or removing a record some time
>> during
 the night.

 What exactly is changing this and how come these values become
>> inconsistant?
 For example:
 Serial on master: 1441509183
 Serial on replica: 1441597213

 Is this expected?

 Kind Regards,

 David



>>> Hello,
>>>
>>> does the replication between master and replica works?
>>
>> SOA is specific for replica (as IPA provides multi-master DNS) and is not
>> replicated. SOA serial in each zone is incremented upon BIND restart so
>> e.g.
>> logrotate during night might cause SOA to increment.
>>
>> --
>> 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] SOA Serial changes overnight and is inconsisstent with replica

[Martin Basti]

On 09/07/2015 03:00 PM, David Dejaeghere wrote:

Hello,

I noticed on the couple of installs that I am running that my zones 
have different soa serial values on both master and replica.  I also 
noticed that this value is changing without adding or removing a 
record some time during the night.


What exactly is changing this and how come these values become 
inconsistant?

For example:
Serial on master: 1441509183
Serial on replica: 1441597213

Is this expected?

Kind Regards,

David




Hello,

does the replication between master and replica works?
-- 
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] SOA Serial changes overnight and is inconsisstent with replica

[Petr Spacek]

On 8.9.2015 13:06, Martin Basti wrote:
> 
> 
> On 09/07/2015 03:00 PM, David Dejaeghere wrote:
>> Hello,
>>
>> I noticed on the couple of installs that I am running that my zones have
>> different soa serial values on both master and replica.  I also noticed that
>> this value is changing without adding or removing a record some time during
>> the night.
>>
>> What exactly is changing this and how come these values become inconsistant?
>> For example:
>> Serial on master: 1441509183
>> Serial on replica: 1441597213
>>
>> Is this expected?
>>
>> Kind Regards,
>>
>> David
>>
>>
>>
> Hello,
> 
> does the replication between master and replica works?

SOA is specific for replica (as IPA provides multi-master DNS) and is not
replicated. SOA serial in each zone is incremented upon BIND restart so e.g.
logrotate during night might cause SOA to increment.

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

[Freeipa-users] Slow email responses this week from FreeIPA/SSSD teams at Red Hat

[Alexander Bokovoy]

Hi everyone!

We have a gathering of Red Hat members of FreeIPA and SSSD teams in
Brno, Czech Republic this week with a lot of design and discussion
meetings. Naturally, we try to lock ourselves down in dungeons without
wifi access and without laptops (not!) to avoid distractions and great
weather of early autumn in Southern Moravia. This has unfortunate effect
of reducing our availability on the mailing lists and IRC channels.

We are apologizing in case you have something urgent to help with and
hope that someone will be able to help as time permits.

Once we re-emerge from the dungeons of Red Hat Brno offices, there
will be wiki updates and blog posts about what is discussed and
reflected on. At least, I have plans to do so on a number of topics.

On a brighter note, FreeIPA 4.2.1 is on its way to Fedora 23
repositories. It is currently pending the acceptance to updates-testing
repository so we most likely miss Fedora 23 beta release but it gives us
chances to test FreeIPA 4.1 to 4.2.1 upgrade path before final Fedora 23
release later this autumn.

https://bodhi.fedoraproject.org/updates/FEDORA-2015-15284

Once packages are in the repositories, we'll send a proper announcement
of FreeIPA 4.2.1 release.
--
/ 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] Replacing the "master"

[Steven Jones]

as below,

regards

Steven


8><

But overall, there is a decent HOWTO on the migration on these pages:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html

8><

fraid not, tried it.

== 

 [root@vuwunicoipam004 thing]# ipa-replica-install --setup-ca 
--ip-address=10.100.32.53 --setup-dns --forwarder=10.100.32.31 -U 
replica-info-vuwunicoipam004.x.gpg Checking forwarders, please wait ... 
WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in 
answers Please fix forwarder configuration to enable DNSSEC support. (For BIND 
9 add directive "dnssec-enable yes;" to "options {}") WARNING: DNSSEC 
validation will be disabled Directory Manager (existing master) password: 

CA cannot be installed in CA-less setup. 
[root@vuwunicoipam004 thing]# ==










-- 
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] Ugrading IPA to dogtag? CA?

[Steven Jones]

[root@vuwunicoipam002 jonesst1]# ipactl status
Directory Service: RUNNING
KDC Service: RUNNING
KPASSWD Service: RUNNING
DNS Service: RUNNING
MEMCACHE Service: RUNNING
HTTP Service: RUNNING
[root@vuwunicoipam002 jonesst1]# 

regards

Steven

From: Rob Crittenden 
Sent: Wednesday, 9 September 2015 3:20 a.m.
To: Steven Jones
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Ugrading IPA to dogtag? CA?

Steven Jones wrote:
> RHEL6.7 and IPA 3.0
>
> "self-signed"  not understanding such terminology terribly well, I am not 
> sure at all.
>
> What command will tell me what I have?

Do you have a dogtag CA instance? ipactl status

rob

>
> regards
>
> Steven
>
> 
> From: Rob Crittenden 
> Sent: Saturday, 5 September 2015 1:26 a.m.
> To: Steven Jones
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Ugrading IPA to dogtag? CA?
>
> Steven Jones wrote:
>> It seems I built IPA with self signed certs so I need to upgrade?  is this 
>> possible? and if so how on existing servers?
>
> I think it depends heavily on what version of IPA you are running and
> what you mean by self-signed.
>
> 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] freeipa cert validation failed, SEC_ERROR_UNTRUSTED_ISSUER

[Morgan Marodin]

I've solved this error, reading this forum:
https://www.redhat.com/archives/freeipa-users/2015-July/msg00247.html

But now when I try to trust to my Active Directory I see these errors:

# ipa trust-add --type=ad mydomain.com --admin Administrator --password
Active Directory domain administrator's password:
ipa: ERROR: CIFS server communication error: code "-1073741258",
  message "The connection was refused" (both may be "None")

Here my logs:

==> /var/log/httpd/error_log <==
Failed to connect host 192.168.0.65 on port 135 -
NT_STATUS_CONNECTION_REFUSED
Failed to connect host 192.168.0.65 (srv01.ipa.mydomain.com) on port 135 -
NT_STATUS_CONNECTION_REFUSED.
[Tue Sep 08 15:01:50.859313 2015] [:error] [pid 2221] ipa: INFO:
[jsonserver_kerb] ad...@ipa.mydomain.com: trust_add(u'mydomain.com',
trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'',
all=False, raw=False, version=u'2.112'): RemoteRetrieveError

==> /var/log/samba/log.192.168.0.65 <==
[2015/09/08 15:01:50.833128,  1]
../source3/auth/user_krb5.c:164(get_user_from_kerberos_info)
  Username IPA\admin is invalid on this system
[2015/09/08 15:01:50.833200,  1]
../source3/auth/auth_generic.c:99(auth3_generate_session_info_pac)
  Failed to map kerberos principal to system user (NT_STATUS_LOGON_FAILURE)
[2015/09/08 15:01:50.833236,  1]
../source3/smbd/sesssetup.c:276(reply_sesssetup_and_X_spnego)
  Failed to generate session_info (user and group token) for session setup:
NT_STATUS_ACCESS_DENIED
[2015/09/08 15:01:50.852169,  1]
../source3/auth/user_krb5.c:164(get_user_from_kerberos_info)
  Username IPA\admin is invalid on this system
[2015/09/08 15:01:50.85,  1]
../source3/auth/auth_generic.c:99(auth3_generate_session_info_pac)
  Failed to map kerberos principal to system user (NT_STATUS_LOGON_FAILURE)
[2015/09/08 15:01:50.852256,  1]
../source3/smbd/sesssetup.c:276(reply_sesssetup_and_X_spnego)
  Failed to generate session_info (user and group token) for session setup:
NT_STATUS_ACCESS_DENIED


I don't see any 135 TCP listening port, doing tcpdump I see that it tryes
to do a connection in its 135 port.
What am I missing?

Thanks, Morgan


> Subject: [Freeipa-users] freeipa cert validation failed,
> SEC_ERROR_UNTRUSTED_ISSUER Date: Tue, 08 Sep 2015 11:00:49 +0200
>
> To: 
> Hi everyone.
>
> I've a problem with my new freeipa installation, v4.1.0, over RHEL 7 like
> distribution.
>
> The installation was ok, but now I've some problems operating via CLI:
> # ipa user-show admin
> ipa: ERROR: cert validation failed for "CN=srv01.ipa.mydomain.com,O=
> IPA.MYDOMAIN.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer
> has been marked as not trusted by the user.)
> ipa: ERROR: cannot connect to 'https://srv01.ipa.mydomain.com/ipa/json':
> (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as
> not trusted by the user.
>
> I've got the same problem connectiong via curl, but after doing these
> command for curl now it works, but not for ipa cli operations:
> --
> # certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt
> # certutil -L -d /etc/pki/nssdb
> Certificate Nickname Trust
> Attributes
>
> SSL,S/MIME,JAR/XPI
> IPA CA   CT,C,C
> # cp /etc/ipa/ca.crt /etc/pki/ca-trust/source/anchors/
> # update-ca-trust extract
> --
>
> And also this command doesn't work:
> # ipa trust-add --type=ad mydomain.com --admin Administrator --password
> ipa: ERROR: cert validation failed for "CN=srv01.ipa.mydomain.com,O=
> IPA.MYDOMAIN.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer
> has been marked as not trusted by the user.)
> ipa: ERROR: cannot connect to 'https://srv01.ipa.mydomain.com/ipa/json':
> (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as
> not trusted by the user.
>
> So ... what's the problem?
>
> Let me know, thanks.
> 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] freeipa cert validation failed, SEC_ERROR_UNTRUSTED_ISSUER

[Alexander Bokovoy]

On Tue, 08 Sep 2015, Morgan Marodin wrote:

I've solved this error, reading this forum:
https://www.redhat.com/archives/freeipa-users/2015-July/msg00247.html

But now when I try to trust to my Active Directory I see these errors:

# ipa trust-add --type=ad mydomain.com --admin Administrator --password
Active Directory domain administrator's password:
ipa: ERROR: CIFS server communication error: code "-1073741258",
 message "The connection was refused" (both may be "None")

Here my logs:

==> /var/log/httpd/error_log <==
Failed to connect host 192.168.0.65 on port 135 -
NT_STATUS_CONNECTION_REFUSED
Failed to connect host 192.168.0.65 (srv01.ipa.mydomain.com) on port 135 -
NT_STATUS_CONNECTION_REFUSED.
[Tue Sep 08 15:01:50.859313 2015] [:error] [pid 2221] ipa: INFO:
[jsonserver_kerb] ad...@ipa.mydomain.com: trust_add(u'mydomain.com',
trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'',
all=False, raw=False, version=u'2.112'): RemoteRetrieveError

==> /var/log/samba/log.192.168.0.65 <==
[2015/09/08 15:01:50.833128,  1]
../source3/auth/user_krb5.c:164(get_user_from_kerberos_info)
 Username IPA\admin is invalid on this system

This is your problem. Does your system have SSSD actually running?


List of ports that smbd should be listening on on IPA master:
# netstat -nltup|grep smbd
tcp0  0 0.0.0.0:135 0.0.0.0:* LISTEN  12420/smbd  
tcp0  0 0.0.0.0:139 0.0.0.0:* LISTEN  12417/smbd  
tcp0  0 0.0.0.0:445 0.0.0.0:* LISTEN  12417/smbd  
tcp0  0 0.0.0.0:10240.0.0.0:* LISTEN  12422/smbd  
tcp6   0  0 :::135  :::*  LISTEN  12420/smbd  
tcp6   0  0 :::139  :::*  LISTEN  12417/smbd  
tcp6   0  0 :::445  :::*  LISTEN  12417/smbd  
tcp6   0  0 :::1024 :::*  LISTEN  12422/smbd


--
/ Alexander Bokovoy

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

[Freeipa-users] pfSense DHCP to IPA's BIND dynamic updates success

[John Keates]

So I was having a DNS mess the other day and decided to clean it up.
Before, I was running Unbound on pfSense which then had a domain override to 
the IPA box. It would forward all queries and IPA-wise all was well.
Problem was that the domain was also used for a bunch of other things, like the 
outside world, and DHCP leases, because I want to be able to FQDN my machines 
and VM’s.

At first, I thought I could somehow make a weird multi-master setup, or have 
Unbound rewrite queries or selectively forward or ignore the authoritative 
status of DNS servers, but
that’s a rather nasty hackish way to attempt to fix things, so I went for the 
option to have DHCPd feed it’s leases and updates to BIND, and make Unbound the 
2nd DNS server in case of an IPA meltdown.

This turned out to be not-so-easy as you can’t use GSSAPI on the pfSense box 
and the IPA interface doesn’t allow you to create keys just like that. 
Solution? Manual edits!
Now, I’m not sure if they will be preserved, but since I was using SaltStack to 
manage pretty much everything config-wise, I just make sure it keeps my 
settings around.

Here is how to configure things:

BIND-side:

1. Open /etc/named.conf in a root editor
2. Insert a key like this:

key "dhcp-key" {
   algorithm   hmac-md5;
   secret   “base64_string_here=";
};

Where the string “dhcp-key” can be anything, but you should remember what you 
put in there.
The Secret is a base64 string, if you are slightly clueless about that, use: 
echo “yoursecrethere” | base64
and you will get your base64 string. Stick it in between the quotes and you’re 
good.

3. Next, log in to the IPA UI and go to the Zone you’d like to have DHCP 
dynamically push to.
4. Click settings and turn on “Dynamic update” if it’s not on already
5. Add an update policy, in this format:

grant dhcp-key wildcard * ANY;

This is rather insecure as you give anything that authenticates using the key 
called “dhcp-key” full update rights for all types on that zone.
So if you want to restrict it, do so as you please. I believe it at least wants 
A and  records and probably TXT.

6. Click the update button and you are all set on this end. Note: if you want 
to have reverse lookups as well, you have to repeat step 5 for the reverse zone 
too!

pfSense-side:

1. In pfSense, go to the DHCP server page
2. Enable "Enable registration of DHCP client names in DNS.”
3. Enter the domain name of the zone you configured in IPA for dynamic updates
4. Enter the required fields (IP of the IPA server, the name (which is dhcp-key 
in this example) and the base64 string you generated
5. Press save and you’re good!

A few extra’s:

- You could add IPA as an NTP server here as well
- You should add the IPA server as the 1st DNS server
- You can add pfSense as the 2nd DNS server if you like

Please remember that at this point no DNS-related stuff on pfSense is used 
anymore as all clients will talk to IPA for their DNS needs from now on.
If all you need is the one domain name, for example, if you use a unique domain 
just for internal IPA use, you’re better off using the domain override.

I hope this helps someone, and might work as a basis for more robust and secure 
configuration, as this is something I just came up with today in a test 
environment.

John


-- 
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 cert validation failed, SEC_ERROR_UNTRUSTED_ISSUER

[Morgan Marodin]

Also doing trust manually (as explained here
http://www.freeipa.org/page/Active_Directory_trust_setup) the command fail
in the same mode:
# ipa trust-add --type=ad MYDOMAIN.COM --trust-secret
Shared secret for the trust:
ipa: ERROR: Cannot find specified domain or server name

==> /var/log/httpd/access_log <==
192.168.0.65 - - [08/Sep/2015:17:50:21 +0200] "POST /ipa/session/json
HTTP/1.1" 200 185

==> /var/log/httpd/error_log <==
[Tue Sep 08 17:50:22.183939 2015] [:error] [pid 4265] ipa: INFO:
[jsonserver_session] ad...@ipa.mydomain.com: trust_add(u'MYDOMAIN.COM',
trust_type=u'ad', trust_secret=u'', all=False, raw=False,
version=u'2.112'): NotFound

==> /var/log/samba/log.winbindd-idmap <==
[2015/09/08 17:50:22.178007,  1]
../source3/winbindd/idmap.c:202(idmap_init_domain)
  idmap range not specified for domain *
[2015/09/08 17:50:22.178984,  1]
../source3/winbindd/idmap.c:202(idmap_init_domain)
  idmap range not specified for domain *
[2015/09/08 17:50:22.179771,  1]
../source3/winbindd/idmap.c:202(idmap_init_domain)
  idmap range not specified for domain *
[2015/09/08 17:50:22.179863,  1]
../source3/winbindd/idmap.c:202(idmap_init_domain)
  idmap range not specified for domain *

:( Morgan

2015-09-08 15:21 GMT+02:00 Alexander Bokovoy :

> On Tue, 08 Sep 2015, Morgan Marodin wrote:
>
>> I've solved this error, reading this forum:
>> https://www.redhat.com/archives/freeipa-users/2015-July/msg00247.html
>>
>> But now when I try to trust to my Active Directory I see these errors:
>> 
>> # ipa trust-add --type=ad mydomain.com --admin Administrator --password
>> Active Directory domain administrator's password:
>> ipa: ERROR: CIFS server communication error: code "-1073741258",
>>  message "The connection was refused" (both may be "None")
>>
>> Here my logs:
>> 
>> ==> /var/log/httpd/error_log <==
>> Failed to connect host 192.168.0.65 on port 135 -
>> NT_STATUS_CONNECTION_REFUSED
>> Failed to connect host 192.168.0.65 (srv01.ipa.mydomain.com) on port 135
>> -
>> NT_STATUS_CONNECTION_REFUSED.
>> [Tue Sep 08 15:01:50.859313 2015] [:error] [pid 2221] ipa: INFO:
>> [jsonserver_kerb] ad...@ipa.mydomain.com: trust_add(u'mydomain.com',
>> trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'',
>> all=False, raw=False, version=u'2.112'): RemoteRetrieveError
>>
>> ==> /var/log/samba/log.192.168.0.65 <==
>> [2015/09/08 15:01:50.833128,  1]
>> ../source3/auth/user_krb5.c:164(get_user_from_kerberos_info)
>>  Username IPA\admin is invalid on this system
>>
> This is your problem. Does your system have SSSD actually running?
>
>
> List of ports that smbd should be listening on on IPA master:
> # netstat -nltup|grep smbd
> tcp0  0 0.0.0.0:135 0.0.0.0:* LISTEN
> 12420/smbd  tcp0  0 0.0.0.0:139 0.0.0.0:*
> LISTEN  12417/smbd  tcp0  0 0.0.0.0:445
>0.0.0.0:* LISTEN  12417/smbd  tcp0  0
> 0.0.0.0:10240.0.0.0:* LISTEN  12422/smbd  tcp6
>0  0 :::135  :::*  LISTEN  12420/smbd
>   tcp6   0  0 :::139  :::*  LISTEN
> 12417/smbd  tcp6   0  0 :::445  :::*
> LISTEN  12417/smbd  tcp6   0  0 :::1024
>  :::*  LISTEN  12422/smbd
>
> --
> / Alexander Bokovoy
>



-- 
Morgan Marodin
email: mor...@marodin.it
mobile: +39.3477829069
-- 
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] Replacing the "master"

[Martin Kosek]

On 09/08/2015 04:23 PM, Martin Kosek wrote:
> On 09/06/2015 10:45 PM, Steven Jones wrote:
>>
>> Martin Kosek wrote:
>>> On 09/04/2015 12:00 AM, Rob Crittenden wrote:
 Steven Jones wrote:
> I have a 3 node IPA cluster, I have replaced the 2 "slaves" however when I
> try and remove the last one the master? it says,
>
> "[root@vuwunicoipam001 thing]# ipa-replica-manage del 
> vuwunicoipam002.
> Directory Manager password:
>
> Deleting a master is irreversible.
> To reconnect to the remote master you will need to prepare a new replica 
> file
> and re-install.
> Continue to delete? [no]: yes
> Deleting this server will orphan 'vuwunicoipam001x  and
> vuwunicoipam003.x
> You will need to reconfigure your replication topology to delete this 
> server.
> [root@vuwunicoipam001 thing]# ipa-replica-manage list
> Directory Manager password:
>
> vuwunicoipam002. master
> vuwunicoipam003. master
> vuwunicoipam001. master
> [root@vuwunicoipam001 thing]#"
>
> So how do I re-configure?

 Every server is a master. The only differences may be the services running 
 (CA
 and/or DNS) and only one generates the CRL and manages certificate renewal.
 Otherwise they are all equal masters.

 This doesn't show the topology. Were I to guess it looks like:

 001
/  \
 002  003

 So you need to run ipa-replica-manage connect vuwunicoipam002 
 vuwunicoipam003

>>
>> Did that,
>>
>> Topology is now, 
>>
>>   002
>>/  \
>> 001 - 003
>>
>> We lost 001 so had to promote 002 to the "master".
>>
>> I dont recall nor can find anything in the docs on this process, maybe 
>> update you docs to reflect this essential step?
>>
>>> However, in this case this should not be a problem AFAIK, given that
>>> ipa-replica-manage tries to preserve the DNA range, from FreeIPA 3.2:
>>>
>>> https://fedorahosted.org/freeipa/ticket/3321
>>
>> RHEL6.7, IPA 3.0.
>>
>> I am trying to upgrade to RHEL7.1 and IPA4.1 and want to fix any mistakes 
>> made when the setup was first built in RHEL6.2

BTW, this depends on what type of mistakes you did. Not all can be easily fixed
(like wrong realm for example).

But overall, there is a decent HOWTO on the migration on these pages:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html

>>
>> "Also be aware of the DNA config"
>>
>> oh joyall these hidden land mines to discover.
>>
>> :(
>>
>> I suppose the next Q is what queries do I have to run in order to collect 
>> all the relevant [mis-]config to compare against the ideal and then plan to 
>> fix these, and what is the ideal?
> 
> You can check "man ipa-replica-manage" for more practical information about 
> DNA
> range updates and to see the commands that can be used to show or modify the
> DNA ranges with the servers in case something goes wrong.
> 
> I do not think this blocks the migration in any way, you should just be aware
> and know where to look in case user-add starts to fail because of depleted 
> range.
> 
> Martin
> 

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

Re: [Freeipa-users] Ugrading IPA to dogtag? CA?

[Rob Crittenden]

Steven Jones wrote:

RHEL6.7 and IPA 3.0

"self-signed"  not understanding such terminology terribly well, I am not sure 
at all.

What command will tell me what I have?


Do you have a dogtag CA instance? ipactl status

rob



regards

Steven


From: Rob Crittenden 
Sent: Saturday, 5 September 2015 1:26 a.m.
To: Steven Jones
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Ugrading IPA to dogtag? CA?

Steven Jones wrote:

It seems I built IPA with self signed certs so I need to upgrade?  is this 
possible? and if so how on existing servers?


I think it depends heavily on what version of IPA you are running and
what you mean by self-signed.

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] freeipa cert validation failed, SEC_ERROR_UNTRUSTED_ISSUER

[Alexander Bokovoy]

On Tue, 08 Sep 2015, Morgan Marodin wrote:

Also doing trust manually (as explained here
http://www.freeipa.org/page/Active_Directory_trust_setup) the command fail
in the same mode:
# ipa trust-add --type=ad MYDOMAIN.COM --trust-secret
Shared secret for the trust:
ipa: ERROR: Cannot find specified domain or server name

==> /var/log/httpd/access_log <==
192.168.0.65 - - [08/Sep/2015:17:50:21 +0200] "POST /ipa/session/json
HTTP/1.1" 200 185

==> /var/log/httpd/error_log <==
[Tue Sep 08 17:50:22.183939 2015] [:error] [pid 4265] ipa: INFO:
[jsonserver_session] ad...@ipa.mydomain.com: trust_add(u'MYDOMAIN.COM',
trust_type=u'ad', trust_secret=u'', all=False, raw=False,
version=u'2.112'): NotFound

Enable debugging as instructed on the page you refer above, and provide
me with the output as the pages tells you.


--
/ 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] Antwort: Re: Antwort: Re: Faulty LDAP record

[Rob Crittenden]

Christoph Kaminski wrote:

Youenn PIOLET  schrieb am 07.09.2015 14:13:35:

 > Von: Youenn PIOLET 
 > An: Christoph Kaminski 
 > Kopie: Ludwig Krispenz , freeipa-users@redhat.com
 > Datum: 07.09.2015 14:16
 > Betreff: Re: [Freeipa-users] Antwort: Re: Faulty LDAP record
 >
 > Hi,
 > Did you try to restart the directory server?
 > I had a similar experience in compat tree, maybe your problem is
 > some kind of "ghost" entry that will not reappear after a restart.
 >
 > Regards,
 >

yep tried it already...


I'd double-check the dn using ldapsearch.

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] freeipa cert validation failed, SEC_ERROR_UNTRUSTED_ISSUER

[Morgan Marodin]

Hi Alexander, thanks for your support.

These are my open ports after running sssd:
# netstat -nltup | grep smbd
tcp0  0 0.0.0.0:139 0.0.0.0:*
LISTEN  3149/smbd
tcp0  0 0.0.0.0:445 0.0.0.0:*
LISTEN  3149/smbd

After running SSD error doing trust changes:
# ipa trust-add --type=ad mydomain.com --admin Administrator --password
Active Directory domain administrator's password:
ipa: ERROR: Cannot find specified domain or server name

Logs:
==> /var/log/httpd/error_log <==
[Tue Sep 08 15:14:46.486031 2015] [:error] [pid 2221] ipa: INFO:
[jsonserver_session] ad...@ipa.mydomain.com: trust_add(u'mydomain.com',
trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'',
realm_server=u'srv01.MYDOMAIN.com', all=False, raw=False,
version=u'2.112'): NotFound

==> /var/log/samba/log.winbindd-idmap <==
[2015/09/08 15:14:46.482578,  1]
../source3/winbindd/idmap.c:202(idmap_init_domain)
  idmap range not specified for domain *
[2015/09/08 15:14:46.483715,  1]
../source3/winbindd/idmap.c:202(idmap_init_domain)
  idmap range not specified for domain *

But DNS seems ok:

# dig SRV _ldap._tcp.ipa.mydomain.com @dc01.mydomain.com

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.5 <<>> SRV _ldap._
tcp.ipa.mydomain.com @dc01.mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47124
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;_ldap._tcp.ipa.mydomain.com. IN  SRV

;; ANSWER SECTION:
_ldap._tcp.ipa.mydomain.com. 83913 IN SRV 0 100 389
srv01.ipa.mydomain.com.

;; ADDITIONAL SECTION:
srv01.ipa.mydomain.com. 3600 IN   A   192.168.0.65

;; Query time: 1 msec
;; SERVER: 192.168.0.31#53(192.168.0.31)
;; WHEN: Tue Sep 08 15:39:03 CEST 2015
;; MSG SIZE  rcvd: 122

# dig SRV _ldap._tcp.ipa.mydomain.com @localhost

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.5 <<>> SRV _ldap._
tcp.ipa.mydomain.com @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18190
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.ipa.mydomain.com. IN  SRV

;; ANSWER SECTION:
_ldap._tcp.ipa.mydomain.com. 86400 IN SRV 0 100 389
srv01.ipa.mydomain.com.

;; AUTHORITY SECTION:
ipa.mydomain.com. 86400   IN  NS  srv01.ipa.mydomain.com.

;; ADDITIONAL SECTION:
srv01.ipa.mydomain.com. 86400 IN  A   192.168.0.65

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 08 15:32:50 CEST 2015
;; MSG SIZE  rcvd: 136

# dig SRV _ldap._tcp.mydomain.com @dc01.mydomain.com

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.5 <<>> SRV _ldap._tcp.mydomain.com @
dc01.mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60503
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;_ldap._tcp.mydomain.com. IN  SRV

;; ANSWER SECTION:
_ldap._tcp.mydomain.com. 600  IN  SRV 0 100 389 dc02.mydomain.com.
_ldap._tcp.mydomain.com. 600  IN  SRV 0 100 389 dc01.mydomain.com.

;; ADDITIONAL SECTION:
dc02.mydomain.com. 3600   IN  A   192.168.0.15
dc01.mydomain.com. 3600   IN  A   192.168.0.31

;; Query time: 1 msec
;; SERVER: 192.168.0.31#53(192.168.0.31)
;; WHEN: Tue Sep 08 15:33:27 CEST 2015
;; MSG SIZE  rcvd: 172

# dig SRV _ldap._tcp.mydomain.com @localhost

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.5 <<>> SRV _ldap._tcp.mydomain.com
@localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36890
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.mydomain.com. IN  SRV

;; ANSWER SECTION:
_ldap._tcp.mydomain.com. 600  IN  SRV 0 100 389 dc02.mydomain.com.
_ldap._tcp.mydomain.com. 600  IN  SRV 0 100 389 dc01.mydomain.com.

;; AUTHORITY SECTION:
.   78287   IN  NS  c.root-servers.net.
.   78287   IN  NS  g.root-servers.net.
.   78287   IN  NS  f.root-servers.net.
.   78287   IN  NS  e.root-servers.net.
.   78287   IN  NS  i.root-servers.net.
.   78287   IN  NS  b.root-servers.net.
.   78287   IN  NS  d.root-servers.net.
.   78287   IN  NS  m.root-servers.net.
.   78287   IN  NS  h.root-servers.net.
.   78287   IN  NS  a.root-servers.net.
.   78287   IN  NS  

Re: [Freeipa-users] Replacing the "master"

[Martin Kosek]

On 09/06/2015 10:45 PM, Steven Jones wrote:
> 
> Martin Kosek wrote:
>> On 09/04/2015 12:00 AM, Rob Crittenden wrote:
>>> Steven Jones wrote:
 I have a 3 node IPA cluster, I have replaced the 2 "slaves" however when I
 try and remove the last one the master? it says,

 "[root@vuwunicoipam001 thing]# ipa-replica-manage del 
 vuwunicoipam002.
 Directory Manager password:

 Deleting a master is irreversible.
 To reconnect to the remote master you will need to prepare a new replica 
 file
 and re-install.
 Continue to delete? [no]: yes
 Deleting this server will orphan 'vuwunicoipam001x  and
 vuwunicoipam003.x
 You will need to reconfigure your replication topology to delete this 
 server.
 [root@vuwunicoipam001 thing]# ipa-replica-manage list
 Directory Manager password:

 vuwunicoipam002. master
 vuwunicoipam003. master
 vuwunicoipam001. master
 [root@vuwunicoipam001 thing]#"

 So how do I re-configure?
>>>
>>> Every server is a master. The only differences may be the services running 
>>> (CA
>>> and/or DNS) and only one generates the CRL and manages certificate renewal.
>>> Otherwise they are all equal masters.
>>>
>>> This doesn't show the topology. Were I to guess it looks like:
>>>
>>> 001
>>>/  \
>>> 002  003
>>>
>>> So you need to run ipa-replica-manage connect vuwunicoipam002 
>>> vuwunicoipam003
>>>
> 
> Did that,
> 
> Topology is now, 
> 
>   002
>/  \
> 001 - 003
> 
> We lost 001 so had to promote 002 to the "master".
> 
> I dont recall nor can find anything in the docs on this process, maybe update 
> you docs to reflect this essential step?
> 
>> However, in this case this should not be a problem AFAIK, given that
>> ipa-replica-manage tries to preserve the DNA range, from FreeIPA 3.2:
>>
>> https://fedorahosted.org/freeipa/ticket/3321
> 
> RHEL6.7, IPA 3.0.
> 
> I am trying to upgrade to RHEL7.1 and IPA4.1 and want to fix any mistakes 
> made when the setup was first built in RHEL6.2
> 
> "Also be aware of the DNA config"
> 
> oh joyall these hidden land mines to discover.
> 
> :(
> 
> I suppose the next Q is what queries do I have to run in order to collect all 
> the relevant [mis-]config to compare against the ideal and then plan to fix 
> these, and what is the ideal?

You can check "man ipa-replica-manage" for more practical information about DNA
range updates and to see the commands that can be used to show or modify the
DNA ranges with the servers in case something goes wrong.

I do not think this blocks the migration in any way, you should just be aware
and know where to look in case user-add starts to fail because of depleted 
range.

Martin

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

[Freeipa-users] Vector/hi-res logo

[Ian Pilcher]

Now that I'm actually using IPA authentication for a few services within
my house, I'm going to set up a simple "start page" with a few links,
including a link to IPA web UI for password changes.  I'd like to use
the FreeIPA logo, but I've only been able to find very small and/or
fuzzy versions.

Does anyone know where I can find a high-resolution or vector version of
the logo?

Thanks!

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


--
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] pfSense DHCP to IPA's BIND dynamic updates success

[Alexander Bokovoy]

On Wed, 09 Sep 2015, John Keates wrote:

So I was having a DNS mess the other day and decided to clean it up.
Before, I was running Unbound on pfSense which then had a domain
override to the IPA box. It would forward all queries and IPA-wise all
was well.  Problem was that the domain was also used for a bunch of
other things, like the outside world, and DHCP leases, because I want
to be able to FQDN my machines and VM’s.

At first, I thought I could somehow make a weird multi-master setup, or
have Unbound rewrite queries or selectively forward or ignore the
authoritative status of DNS servers, but that’s a rather nasty hackish
way to attempt to fix things, so I went for the option to have DHCPd
feed it’s leases and updates to BIND, and make Unbound the 2nd DNS
server in case of an IPA meltdown.

This turned out to be not-so-easy as you can’t use GSSAPI on the
pfSense box and the IPA interface doesn’t allow you to create keys just
like that. Solution? Manual edits!  Now, I’m not sure if they will be
preserved, but since I was using SaltStack to manage pretty much
everything config-wise, I just make sure it keeps my settings around.

Here is how to configure things:

BIND-side:

1. Open /etc/named.conf in a root editor
2. Insert a key like this:

key "dhcp-key" {
  algorithm   hmac-md5;
  secret“base64_string_here=";
};

Where the string “dhcp-key” can be anything, but you should remember
what you put in there.  The Secret is a base64 string, if you are
slightly clueless about that, use: echo “yoursecrethere” | base64
and you will get your base64 string. Stick it in between the quotes and
you’re good.

3. Next, log in to the IPA UI and go to the Zone you’d like to have DHCP 
dynamically push to.
4. Click settings and turn on “Dynamic update” if it’s not on already
5. Add an update policy, in this format:

grant dhcp-key wildcard * ANY;

This is rather insecure as you give anything that authenticates using
the key called “dhcp-key” full update rights for all types on that
zone.  So if you want to restrict it, do so as you please. I believe it
at least wants A and  records and probably TXT.

6. Click the update button and you are all set on this end. Note: if
you want to have reverse lookups as well, you have to repeat step 5 for
the reverse zone too!

pfSense-side:

1. In pfSense, go to the DHCP server page
2. Enable "Enable registration of DHCP client names in DNS.”
3. Enter the domain name of the zone you configured in IPA for dynamic updates
4. Enter the required fields (IP of the IPA server, the name (which is dhcp-key 
in this example) and the base64 string you generated
5. Press save and you’re good!

A few extra’s:

- You could add IPA as an NTP server here as well
- You should add the IPA server as the 1st DNS server
- You can add pfSense as the 2nd DNS server if you like

Please remember that at this point no DNS-related stuff on pfSense is
used anymore as all clients will talk to IPA for their DNS needs from
now on.  If all you need is the one domain name, for example, if you
use a unique domain just for internal IPA use, you’re better off using
the domain override.

I hope this helps someone, and might work as a basis for more robust
and secure configuration, as this is something I just came up with
today in a test environment.

This looks reasonable. You may want to put your key definition into something 
like
/etc/named/my-dhcp-keys.conf and include it from there via 'include'
statements but I think we don't upgrade named.conf after it was
originally created.

John, could you please add this to FreeIPA wiki?
--
/ 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