Re: [Freeipa-users] FreeIPA and slave MIT slave KDCs

[Diogenes S. Jesus]

Thanks Petr.

It seems like the only way to do it right now is to dump the keytab and
copy it to slave KDCs, as I couldn't find a way to have MIT Kerberos to use
the master key stored in the LDAP directly.

MIT Kerberos doesn't really support a master key stored elsewhere other
than using "key_stash_file" AFAIK, so I'm wondering how FreeIPA has
actually implemented it (I couldn't find any reference for it in the
kerberos conf files).

My use case involves having a "FreeIPA slave"  - a streamlined version
which will only provide authentication (via Kerberos). Sure, I can make a
standard replica and firewall what I don't wanna use, but when stretching
your authentication infrastructure you don't necessary need to expose all
other services FreeIPA provides, since that increases your attack surface.

Best regards

On Fri, Jul 22, 2016 at 10:14 AM, Petr Spacek  wrote:

> On 21.7.2016 22:05, Diogenes S. Jesus wrote:
> > Hi everyone.
> >
> > I'm currently planning on deploying FreeIPA as the Master KDC (among
> other
> > things to leverage from the API and some other built-in features - like
> > replicas).
> > However I find (correct if I'm wrong) FreeIPA not very modular -
> therefore
> > I would like to know what's the strategy when deploying slave KDCs.
> >
> > I've seen this thread
> >  September/msg00319.html>
> > but I
> > don't really want to have a replica - the idea was to deploy a separate
> box
> > only running KDC - since the authentication is delegated to RADIUS for
> > Authentication, I don't need to expose LDAP Master to KDC slaves - If
> yes,
> > I would provide a read-only LDAP replica..
> >
> >
> > For starters, where is the FreeIPA KDC stash file stored?
>
> AFAIK there is no prior art in setting up MIT KDC slaves. First of all,
> FreeIPA does not use stash file and stores master key in LDAP instead.
>
> You can retrieve equivalent of stash file using following command:
>
> $ ipa-getkeytab --retrieve --principal K/M@ -k /tmp/stash.keytab
> --binddn='cn=Directory manager' --bindpw=''
>
> *Make sure* that --retrieve option is present otherwise it will destroy
> your
> Kerberos database.
>
> The rest is up to your experimentation. I wish you good luck and please
> report
> your findings back to the mailing list!
>
> --
> 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
>



-- 



Diogenes S. de Jesus
-- 
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] replica_generate_next_csn messages in dirsrv error logs

[John Desantis]

Ludwig,

> unfortunately this is not enough to determine what is going on. The
> intersting generated/used csn is only logged in the
> corresponding RESULT message and these are only the replication connections,
> it would be necessary to see the
> original ADD operation, was it added once or twice by a client ?
> you could pick one entry eg server-6-3-sp and grep for all references in the
> access logs of both servers  (maybe there are mods as well) and then
> get also get the RESULT line for the ops found

Here are the updated log snippets looking for ADD and RESULT:

PROD:11:20:13-root@REPLICA:/var/log/dirsrv/slapd-DOM-DOM-DOM
# grep -E '17/Aug/2016:13:50:4.*conn=602.*(RESULT|ADD)' access.2016081*
access.20160817-124811:[17/Aug/2016:13:50:41 -0400] conn=602 op=4139
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-124811:[17/Aug/2016:13:50:41 -0400] conn=602 op=4140
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4141
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4142
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4143
ADD dn="idnsname=server-6-3-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"
access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4143
RESULT err=0 tag=105 nentries=0 etime=0 csn=57b4a4bb00030004
access.20160817-124811:[17/Aug/2016:13:50:44 -0400] conn=602 op=4144
RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4bb00040004
access.20160817-124811:[17/Aug/2016:13:50:44 -0400] conn=602 op=4145
RESULT err=0 tag=103 nentries=0 etime=0
access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4146
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4147
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4148
ADD dn="idnsname=server-6-4-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"
access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4148
RESULT err=0 tag=105 nentries=0 etime=0 csn=57b4a4bb00080004
access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4149
RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4bc00010004
access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4150
RESULT err=0 tag=103 nentries=0 etime=0
access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4151
ADD dn="idnsname=server-6-5-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"
access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4151
RESULT err=0 tag=105 nentries=0 etime=0 csn=57b4a4c100050004
access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4152
RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4c100060004

PROD:11:19:54-root@MASTER:/var/log/dirsrv/slapd-DOM-DOM-DOM
# grep -E '17/Aug/2016:13:50:4.*conn=1395.*(RESULT|ADD)' access.2016081*
access.20160817-111940:[17/Aug/2016:13:50:41 -0400] conn=1395 op=4148
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-111940:[17/Aug/2016:13:50:41 -0400] conn=1395 op=4149
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-111940:[17/Aug/2016:13:50:41 -0400] conn=1395 op=4150
RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4b900050016
access.20160817-111940:[17/Aug/2016:13:50:43 -0400] conn=1395 op=4151
ADD dn="idnsname=server-6-3-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"
access.20160817-111940:[17/Aug/2016:13:50:43 -0400] conn=1395 op=4151
RESULT err=0 tag=105 nentries=0 etime=0
access.20160817-111940:[17/Aug/2016:13:50:44 -0400] conn=1395 op=4152
RESULT err=0 tag=103 nentries=0 etime=1 csn=57b4a4bc0016
access.20160817-111940:[17/Aug/2016:13:50:46 -0400] conn=1395 op=4153
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-111940:[17/Aug/2016:13:50:47 -0400] conn=1395 op=4154
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-111940:[17/Aug/2016:13:50:47 -0400] conn=1395 op=4155
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-111940:[17/Aug/2016:13:50:47 -0400] conn=1395 op=4156
RESULT err=0 tag=120 nentries=0 etime=0
access.20160817-111940:[17/Aug/2016:13:50:48 -0400] conn=1395 op=4157
RESULT err=0 tag=103 nentries=0 etime=1 csn=57b4a4c100010016
access.20160817-111940:[17/Aug/2016:13:50:49 -0400] conn=1395 op=4158
ADD dn="idnsname=server-6-5-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"
access.20160817-111940:[17/Aug/2016:13:50:49 -0400] conn=1395 op=4158
RESULT err=0 tag=105 nentries=0 etime=0
access.20160817-111940:[17/Aug/2016:13:50:49 -0400] conn=1395 op=4159
RESULT err=0 tag=103 nentries=0 etime=0
access.20160817-111940:[17/Aug/2016:13:50:49 -0400] conn=1395 op=4160
RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4c30016

I'm positive that I was the only one performing DNS updates during
this time, and I was only using 1 console.

Thanks,
John DeSantis


2016-08-18 10:09 GMT-04:00 Ludwig Krispenz 

[Freeipa-users] Freeipa 4.2.0 hangs intermittently

[Rakesh Rajasekharan]

Hi

I am migrating to freeipa from openldap and have around 4000 clients

I had openned a another thread on that, but chose to start a new one here
as its a separate issue

I was able to change the nssslapd-maxdescriptors adding an ldif file

cat nsslapd-modify.ldif
dn: cn=config
changetype: modify
replace: nsslapd-maxdescriptors
nsslapd-maxdescriptors: 17000

and running the ldapmodify command

I have now started moving clients running an openldap to Freeipa and have
today moved close to 2000 clients

However, I have noticed that IPA hangs intermittently.

running a kinit admin returns the below error
kinit: Generic error (see e-text) while getting initial credentials

from the /var/log/messages, I see this entry

 prod-ipa-master-int kernel: [104090.315801] TCP: request_sock_TCP:
Possible SYN flooding on port 88. Sending cookies.  Check SNMP counters.
Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Started Session 4885 of
user root.
Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Starting Session 4885 of
user root.
Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Started Session 4886 of
user root.
Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Starting Session 4886 of
user root.
Aug 18 13:02:40 prod-ipa-master-int python[28984]: ansible-command Invoked
with creates=None executable=None shell=True args= removes=None warn=True
chdir=None
Aug 18 13:04:37 prod-ipa-master-int sssd_be: GSSAPI Error: Unspecified GSS
failure.  Minor code may provide more information (KDC returned error
string: PROCESS_TGS)

Could it be possible that its due to the initial load of adding the clients
or is there something else that I need to take care of.

Thanks,

Rakesh
-- 
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-AD ldap acces - account ?

[Jan Karásek]

Great ! Thank you very much. It works ! 

Regards, 
Jan 


From: "Alexander Bokovoy"  
To: "Jan Karásek"  
Cc: freeipa-users@redhat.com 
Sent: Thursday, August 18, 2016 4:03:14 PM 
Subject: Re: [Freeipa-users] IPA-AD ldap acces - account ? 

On Thu, 18 Aug 2016, Jan Karásek wrote: 
>Hi, 
>thank you. We are experiencing problems with LDAP access from IPA 
>servers in IPA-AD scenario with one-way trust (Win 2012). 
> 
>So for ldap access IPA uses the xyz$@domain special trust account. 
>According my lab - this account is on the AD side considered as a 
>member of Authenticated users group. By default Authenticated users are 
>member of group Pre-Windows 2000 Compatible Access, and this group have 
>read permission on object type User and therefore IPA is able to read 
>POSIX attributes from these objects. (tested in my lab environment) 
> 
>In our case - due to security team - there is no possibility for 
>Authenticated users to read user's objects - and then IPA is unable to 
>read objects from AD ldap. So we have situation, where kerberos works 
>OK but we are not able to get POSIX attributes from ldap. 
Create a group that could be granted such access, add TDO object there. 

>This situation could have been solved by adding read permission 
>directly to the IPA access account(TDO), but unfortunately it looks 
>like it is not possible. 
Why is it not possible? The account is in AD, one can always grant 
it more permissions there. 

> 
>Questions : 
> 
>1. Do the IPA depends on ability of Authenticated users group to access 
>user's objects attributes ? 
At the very least, yes. Otherwise you need to grant more permissions to 
the TDO account in AD, even though you cannot directly get access to the 
account from non-advanced UI view. However, even Samba 'net' utility 
works fine: 

1. Create a group in the forest root domain: 
# net rpc group add trust-rpc-readonly -S w12.ad.test -UAdministrator%PASSWORD 

2. Add our TDO object to the group: 
# net rpc group addmem trust-rpc-readonly 'IPAAD$' -S w12.ad.test 
-UAdministrator%PASSWORD 

3. Check that TDO oubject is part of the group 
# net rpc group members trust-read-only -S w12.ad.test -UAdministrator%PASSWORD 
AD\IPAAD$ 

Now you can go to UI and assign specific privileges to the group. 

>2. Is it possible to setup some other "standard" service account for 
>IPA access to AD ldap ? 
No. 

> 
>Thank you, 
>Jan 
> 
> 
> 
>From: "Alexander Bokovoy"  
>To: "Jan Karásek"  
>Cc: freeipa-users@redhat.com 
>Sent: Wednesday, August 17, 2016 4:12:28 PM 
>Subject: Re: [Freeipa-users] IPA-AD ldap acces - account ? 
> 
>On Wed, 17 Aug 2016, Jan Karásek wrote: 
>>Hi, 
>> 
>>please could somebody explain how and and with which account IPA is 
>>accessing DC in IPA - AD trust scenario. Is is possible to simulate 
>>with ldapsearch some query to AD with the same permission as IPA 
>>server? 
>Depends on what trust we have. For two-way trust SSSD on IPA masters 
>uses host/master.ipa.domain@IPA.DOMAIN principal because we map it to a 
>SID with a special well-known RID 'Domain Computers' (-515) and attach 
>an MS-PAC record to the TGT issued for this service principal. 
> 
>For one-way trust SSSD on IPA masters uses so-called TDO account. These 
>are special accounts in AD domains which look like a machine account 
>(FOO$) but instead use NetBIOS name of the trusted forest and have 
>specific attributes associated with it. 
> 
>>We have some issues with reading ldap object from AD and I would like 
>>to simulate that from command line. 
> 
>Simplest way is to do something like this on IPA master for one-way 
>trust: 
> 
># klist -kt /var/lib/sss/keytabs/.keytab 
> 
>notice the principal name there, let's say it is NAME$@TRUST 
> 
># kinit -kt /var/lib/sss/keytabs/.keytab 'NAME$@TRUST' 
># ldapsearch -H ad.dc -Y GSSAPI  
> 
>For two-way trust it is enough to kinit as IPA master host principal: 
> 
># kinit -k 
># ldapsearch -H ad.dc -Y GSSAPI ... 
> 
> 
>-- 
>/ 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 


-- 
/ 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] Admin password no more working

[Deepak Dimri]

Hi All,
While trying to automate IPA client registration programatically, i seems have 
made my admin password out of sync between KDC and 








/etc/krb5.keytab. Now when i try login into ipa GUI via admin i am getting "The 
password or username is incorrect" - though i am trying with the correct 
password that i have been using. Is there anyway i can login to GUI in this 
situation? Is there anyway i can get my admin password reseted or something? i 
can run my ansible playbooks w/out any issues on the linux host but cannot 
login to GUI any more...
Thanks for your great help!
Regards,Deepak-- 
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] replica_generate_next_csn messages in dirsrv error logs

[Ludwig Krispenz]

On 08/18/2016 03:15 PM, John Desantis wrote:

Ludwig,

Thank you for your response!


This is a normal scenario, but you could check if the simultaneous updates
on 4 and 16 are intentional.

In regards to the simultaneous updates, the only items I have noted so far are:

*  The time sync between the master (4) and replica (16) was off by
about 1-2 seconds, with the latter being ahead;
yes, this happens, but the replication protocol tries to handle this, in 
a replication session the supplier and consumer
exchange their ruvs and if the time differs the csn state generator is 
updated with a local or remote offset so that the
generated time is always based on the most advanced clock - on all 
servers. And even if you adjust the system time, the csn

time will never go back.

*  There are continual log entries referencing
"replication-multimaster-extop" and "Netscape Replication End Session"
in the dirsrv "access" logs, and during one of the manifestations of
"replica_generate_next_csn", I found this:

PROD:08:46:08-root@REPLICA:/var/log/dirsrv/slapd-DOM-DOM-DOM
# grep -E '17/Aug/2016:13:50:4.*conn=602.*ADD' access.2016081*
access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4143
ADD dn="idnsname=server-6-3-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"
access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4148
ADD dn="idnsname=server-6-4-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"
access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4151
ADD dn="idnsname=server-6-5-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"

PROD:08:47:44-root@MASTER:/var/log/dirsrv/slapd-DOM-DOM-DOM
# grep -E '17/Aug/2016:13:50:4.*conn=1395.*ADD' access.2016081*
access.20160817-111940:[17/Aug/2016:13:50:43 -0400] conn=1395 op=4151
ADD dn="idnsname=server-6-3-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"
access.20160817-111940:[17/Aug/2016:13:50:49 -0400] conn=1395 op=4158
ADD dn="idnsname=server-6-5-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"

It looks like the entries for server-6-3-sp and 6-5-sp were referenced
twice.  Do you think that the time being off by 1-2 seconds between
the master and replica could be the issue?  The connection 602 is the
replication between the replica and master, and the connection 1395 is
the replication between the master and replica.
unfortunately this is not enough to determine what is going on. The 
intersting generated/used csn is only logged in the
corresponding RESULT message and these are only the replication 
connections, it would be necessary to see the

original ADD operation, was it added once or twice by a client ?
you could pick one entry eg server-6-3-sp and grep for all references in 
the access logs of both servers  (maybe there are mods as well) and then

get also get the RESULT line for the ops found


Since I know these operations were performed using the console via a
for loop 'ipa dnsrecord-add dom.dom.dom server-6-$i-sp
--a-rec=10.250.12.$i' on one of our login nodes, do you think that
specifying an _srv_ record in the DOMAIN configuration with the
address of the master server, e.g.: ipa_server = _srv_,
MASTER.dom.dom.dom could be the issue (coupled with the time syncing)?

I know that these questions are probably leaning more towards the
389ds team, so feel free to pass me over to them if need be.
I think I can address the ds related questions, but I don't know about 
console and dns to assess if the behaviour is normal


Again, thank you very much for responding!

John DeSantis

2016-08-18 4:14 GMT-04:00 Ludwig Krispenz :

On 08/17/2016 08:54 PM, John Desantis wrote:

Hello all,

We've been re-using old host names and IP addresses for a new
deployment of nodes, and recently I've been seeing the messages pasted
below in the slapd-DC.DC.DC "error" log on our nodes.

[17/Aug/2016:10:30:30 -0400] - replica_generate_next_csn:
opcsn=57b475cd00120004 <= basecsn=57b475cf0016, adjusted
opcsn=57b475cf00010004
[17/Aug/2016:11:09:44 -0400] - replica_generate_next_csn:
opcsn=57b47f020004 <= basecsn=57b47f020016, adjusted
opcsn=57b47f030004
[17/Aug/2016:11:09:44 -0400] - replica_generate_next_csn:
opcsn=57b47f040004 <= basecsn=57b47f040016, adjusted
opcsn=57b47f050004
[17/Aug/2016:11:10:33 -0400] - replica_generate_next_csn:
opcsn=57b47f2f0014 <= basecsn=57b47f320016, adjusted
opcsn=57b47f330004
[17/Aug/2016:13:50:45 -0400] - replica_generate_next_csn:
opcsn=57b4a4bb00090004 <= basecsn=57b4a4bc0016, adjusted
opcsn=57b4a4bc00010004
[17/Aug/2016:13:52:54 -0400] - replica_generate_next_csn:
opcsn=57b4a53e000a0004 <= basecsn=57b4a53f0016, adjusted
opcsn=57b4a53f00010004
[17/Aug/2016:13:53:15 -0400] - replica_generate_next_csn:
opcsn=57b4a55200070004 <= basecsn=57b4a5530016, adjusted
opcsn=57b4a55300010004
[17/Aug/2016:13:53:32 -0400] - replica_generate_next_csn:

Re: [Freeipa-users] IPA-AD ldap acces - account ?

[Alexander Bokovoy]

On Thu, 18 Aug 2016, Jan Karásek wrote:

Hi,
thank you. We are experiencing problems with LDAP access from IPA
servers in IPA-AD scenario with one-way trust (Win 2012).

So for ldap access IPA uses the xyz$@domain special trust account.
According my lab - this account is on the AD side considered as a
member of Authenticated users group. By default Authenticated users are
member of group Pre-Windows 2000 Compatible Access, and this group have
read permission on object type User and therefore IPA is able to read
POSIX attributes from these objects. (tested in my lab environment)

In our case - due to security team - there is no possibility for
Authenticated users to read user's objects - and then IPA is unable to
read objects from AD ldap. So we have situation, where kerberos works
OK but we are not able to get POSIX attributes from ldap.

Create a group that could be granted such access, add TDO object there.


This situation could have been solved by adding read permission
directly to the IPA access account(TDO), but unfortunately it looks
like it is not possible.

Why is it not possible? The account is in AD, one can always grant
it more permissions there.



Questions :

1. Do the IPA depends on ability of Authenticated users group to access
user's objects attributes ?

At the very least, yes. Otherwise you need to grant more permissions to
the TDO account in AD, even though you cannot directly get access to the
account from non-advanced UI view. However, even Samba 'net' utility
works fine:

1. Create a group in the forest root domain:
# net rpc group add trust-rpc-readonly -S w12.ad.test -UAdministrator%PASSWORD

2. Add our TDO object to the group:
# net rpc group addmem trust-rpc-readonly 'IPAAD$' -S w12.ad.test 
-UAdministrator%PASSWORD

3. Check that TDO oubject is part of the group
# net rpc group members trust-read-only -S w12.ad.test -UAdministrator%PASSWORD
AD\IPAAD$

Now you can go to UI and assign specific privileges to the group.


2. Is it possible to setup some other "standard" service account for
IPA access to AD ldap ?

No.



Thank you,
Jan



From: "Alexander Bokovoy" 
To: "Jan Karásek" 
Cc: freeipa-users@redhat.com
Sent: Wednesday, August 17, 2016 4:12:28 PM
Subject: Re: [Freeipa-users] IPA-AD ldap acces - account ?

On Wed, 17 Aug 2016, Jan Karásek wrote:

Hi,

please could somebody explain how and and with which account IPA is
accessing DC in IPA - AD trust scenario. Is is possible to simulate
with ldapsearch some query to AD with the same permission as IPA
server?

Depends on what trust we have. For two-way trust SSSD on IPA masters
uses host/master.ipa.domain@IPA.DOMAIN principal because we map it to a
SID with a special well-known RID 'Domain Computers' (-515) and attach
an MS-PAC record to the TGT issued for this service principal.

For one-way trust SSSD on IPA masters uses so-called TDO account. These
are special accounts in AD domains which look like a machine account
(FOO$) but instead use NetBIOS name of the trusted forest and have
specific attributes associated with it.


We have some issues with reading ldap object from AD and I would like
to simulate that from command line.


Simplest way is to do something like this on IPA master for one-way
trust:

# klist -kt /var/lib/sss/keytabs/.keytab

notice the principal name there, let's say it is NAME$@TRUST

# kinit -kt /var/lib/sss/keytabs/.keytab 'NAME$@TRUST'
# ldapsearch -H ad.dc -Y GSSAPI 

For two-way trust it is enough to kinit as IPA master host principal:

# kinit -k
# ldapsearch -H ad.dc -Y GSSAPI ...


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



--
/ 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] FreeIPA / CentOS 7.2 / Issues on Startup

[Martin Kosek]

On 08/18/2016 12:48 AM, Devin Acosta wrote:
> 
> My first primary FreeIPA Master server has gone belly up. When I try to start 
> the server it shows this message in the "error' log. However the other issue 
> i 
> have is when I try to start the server using "ipactl start" it times out 
> after 
> 300 seconds, how do I get past this issue?
> 
> [17/Aug/2016:22:44:57 +] SSL Initialization - Configured SSL version 
> range: 
> min: TLS1.0, max: TLS1.2
> [17/Aug/2016:22:44:57 +] - 389-Directory/1.3.4.0  
> B2016.215.1556 starting up
> [17/Aug/2016:22:44:57 +] - WARNING: changelog: entry cache size 2097152B 
> is 
> less than db size 28016640B; We recommend to increase the entry cache size 
> nsslapd-cachememsize.
> [17/Aug/2016:22:44:57 +] - Detected Disorderly Shutdown last time 
> Directory 
> Server was running, recovering database.
> 
> 
> Any help is greatly needed!!

My best guess is that your
/etc/dirsrv/slapd-YOUR-REALM/dse.ldif
got damaged when DS crashed/whatever and it now does not export the 636 port,
which is being checked by ipactl start.

You can try to start just the DS service with "service start dirsrv@YOUR-REALM"
and see if it opens port 636 with

netstat -putnl | grep 636
tcp6   0  0 :::636  :::*LISTEN
48550/ns-slapd

If it is not open, you can try to stop DS and use other dse.ldif from the
directory above, that is not corrupt. There should be some backups.

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] ipa-cert-agent, Object Signing Cert certificate renewal

[Rob Crittenden]

realstarhealer wrote:

Hi,

I am in charge for a freeipa 4.1.0.18.el7 server with ldap backend and
noticed some expired certificates recently. Most of them but 2 are
auto-renewing by certmonger as I checked. All of them are self signed.

"CN=ipa-ca-agent" and "CN=Object Signing Cert" are not subscribed by
certmonger, ipa-ca-agent expired some days ago and has not been renewed.
Second one expires soon. No consequences noticed so far.
Can you tell me what they both are for and - if needed - how I should
renew that separately? Preferable with certmonger. An Output how the
tracking config should look like would be nice.


The object signing cert can probably be ignored. This was used to sign a 
jar file used to automatically configure Firefox but that approach 
doesn't work any more.


The agent cert is used by IPA to communicate to dogtag so yeah, that's 
pretty important.


Since it is expired you'd need to go back in time to renew it. 
Restarting the certmonger process is the simplest method to force it to 
try to renew.


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] replica_generate_next_csn messages in dirsrv error logs

[John Desantis]

Ludwig,

Thank you for your response!

> This is a normal scenario, but you could check if the simultaneous updates
> on 4 and 16 are intentional.

In regards to the simultaneous updates, the only items I have noted so far are:

*  The time sync between the master (4) and replica (16) was off by
about 1-2 seconds, with the latter being ahead;
*  There are continual log entries referencing
"replication-multimaster-extop" and "Netscape Replication End Session"
in the dirsrv "access" logs, and during one of the manifestations of
"replica_generate_next_csn", I found this:

PROD:08:46:08-root@REPLICA:/var/log/dirsrv/slapd-DOM-DOM-DOM
# grep -E '17/Aug/2016:13:50:4.*conn=602.*ADD' access.2016081*
access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4143
ADD dn="idnsname=server-6-3-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"
access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4148
ADD dn="idnsname=server-6-4-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"
access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4151
ADD dn="idnsname=server-6-5-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"

PROD:08:47:44-root@MASTER:/var/log/dirsrv/slapd-DOM-DOM-DOM
# grep -E '17/Aug/2016:13:50:4.*conn=1395.*ADD' access.2016081*
access.20160817-111940:[17/Aug/2016:13:50:43 -0400] conn=1395 op=4151
ADD dn="idnsname=server-6-3-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"
access.20160817-111940:[17/Aug/2016:13:50:49 -0400] conn=1395 op=4158
ADD dn="idnsname=server-6-5-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom"

It looks like the entries for server-6-3-sp and 6-5-sp were referenced
twice.  Do you think that the time being off by 1-2 seconds between
the master and replica could be the issue?  The connection 602 is the
replication between the replica and master, and the connection 1395 is
the replication between the master and replica.

Since I know these operations were performed using the console via a
for loop 'ipa dnsrecord-add dom.dom.dom server-6-$i-sp
--a-rec=10.250.12.$i' on one of our login nodes, do you think that
specifying an _srv_ record in the DOMAIN configuration with the
address of the master server, e.g.: ipa_server = _srv_,
MASTER.dom.dom.dom could be the issue (coupled with the time syncing)?

I know that these questions are probably leaning more towards the
389ds team, so feel free to pass me over to them if need be.

Again, thank you very much for responding!

John DeSantis

2016-08-18 4:14 GMT-04:00 Ludwig Krispenz :
>
> On 08/17/2016 08:54 PM, John Desantis wrote:
>>
>> Hello all,
>>
>> We've been re-using old host names and IP addresses for a new
>> deployment of nodes, and recently I've been seeing the messages pasted
>> below in the slapd-DC.DC.DC "error" log on our nodes.
>>
>> [17/Aug/2016:10:30:30 -0400] - replica_generate_next_csn:
>> opcsn=57b475cd00120004 <= basecsn=57b475cf0016, adjusted
>> opcsn=57b475cf00010004
>> [17/Aug/2016:11:09:44 -0400] - replica_generate_next_csn:
>> opcsn=57b47f020004 <= basecsn=57b47f020016, adjusted
>> opcsn=57b47f030004
>> [17/Aug/2016:11:09:44 -0400] - replica_generate_next_csn:
>> opcsn=57b47f040004 <= basecsn=57b47f040016, adjusted
>> opcsn=57b47f050004
>> [17/Aug/2016:11:10:33 -0400] - replica_generate_next_csn:
>> opcsn=57b47f2f0014 <= basecsn=57b47f320016, adjusted
>> opcsn=57b47f330004
>> [17/Aug/2016:13:50:45 -0400] - replica_generate_next_csn:
>> opcsn=57b4a4bb00090004 <= basecsn=57b4a4bc0016, adjusted
>> opcsn=57b4a4bc00010004
>> [17/Aug/2016:13:52:54 -0400] - replica_generate_next_csn:
>> opcsn=57b4a53e000a0004 <= basecsn=57b4a53f0016, adjusted
>> opcsn=57b4a53f00010004
>> [17/Aug/2016:13:53:15 -0400] - replica_generate_next_csn:
>> opcsn=57b4a55200070004 <= basecsn=57b4a5530016, adjusted
>> opcsn=57b4a55300010004
>> [17/Aug/2016:13:53:32 -0400] - replica_generate_next_csn:
>> opcsn=57b4a56200090004 <= basecsn=57b4a5640016, adjusted
>> opcsn=57b4a56400010004
>
> Each modification (add/del/mod) gets a csn assignged used in replication
> update resolution. And each assigned csn has to newer than an existing one.
> The messages you see is from code that double checks that the entry doesn't
> have already a lareg csn - and adjusts it.
> The logs indicate that entries are more or less concurrently updated on
> replica 4 and 16, and the updates from16 are received while processing the
> updates on 4.
> This is a normal scenario, but you could check if the simultaneous updates
> on 4 and 16 are intentional.
>
>>
>> They seem to only occur when updating DNS entries, whether on the
>> console or via the GUI (tail -f'ing the log).
>>
>> A search in this mailing-list returns nothing, but a message is found
>> on the 389-ds list [1];  it seems to suggest that the messages aren't
>> fatal and are purely informational, yet if they are 

Re: [Freeipa-users] IPA-AD ldap acces - account ?

[Jan Karásek]

Hi, 
thank you. We are experiencing problems with LDAP access from IPA servers in 
IPA-AD scenario with one-way trust (Win 2012). 

So for ldap access IPA uses the xyz$@domain special trust account. According my 
lab - this account is on the AD side considered as a member of Authenticated 
users group. By default Authenticated users are member of group Pre-Windows 
2000 Compatible Access, and this group have read permission on object type User 
and therefore IPA is able to read POSIX attributes from these objects. (tested 
in my lab environment) 

In our case - due to security team - there is no possibility for Authenticated 
users to read user's objects - and then IPA is unable to read objects from AD 
ldap. So we have situation, where kerberos works OK but we are not able to get 
POSIX attributes from ldap. 

This situation could have been solved by adding read permission directly to the 
IPA access account(TDO), but unfortunately it looks like it is not possible. 

Questions : 

1. Do the IPA depends on ability of Authenticated users group to access user's 
objects attributes ? 
2. Is it possible to setup some other "standard" service account for IPA access 
to AD ldap ? 

Thank you, 
Jan 



From: "Alexander Bokovoy"  
To: "Jan Karásek"  
Cc: freeipa-users@redhat.com 
Sent: Wednesday, August 17, 2016 4:12:28 PM 
Subject: Re: [Freeipa-users] IPA-AD ldap acces - account ? 

On Wed, 17 Aug 2016, Jan Karásek wrote: 
>Hi, 
> 
>please could somebody explain how and and with which account IPA is 
>accessing DC in IPA - AD trust scenario. Is is possible to simulate 
>with ldapsearch some query to AD with the same permission as IPA 
>server? 
Depends on what trust we have. For two-way trust SSSD on IPA masters 
uses host/master.ipa.domain@IPA.DOMAIN principal because we map it to a 
SID with a special well-known RID 'Domain Computers' (-515) and attach 
an MS-PAC record to the TGT issued for this service principal. 

For one-way trust SSSD on IPA masters uses so-called TDO account. These 
are special accounts in AD domains which look like a machine account 
(FOO$) but instead use NetBIOS name of the trusted forest and have 
specific attributes associated with it. 

>We have some issues with reading ldap object from AD and I would like 
>to simulate that from command line. 

Simplest way is to do something like this on IPA master for one-way 
trust: 

# klist -kt /var/lib/sss/keytabs/.keytab 

notice the principal name there, let's say it is NAME$@TRUST 

# kinit -kt /var/lib/sss/keytabs/.keytab 'NAME$@TRUST' 
# ldapsearch -H ad.dc -Y GSSAPI  

For two-way trust it is enough to kinit as IPA master host principal: 

# kinit -k 
# ldapsearch -H ad.dc -Y GSSAPI ... 


-- 
/ 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] DNS migration to FreeIPA and import of existing DNSSEC keys

[Petr Spacek]

On 17.8.2016 19:58, Guido Schmitz wrote:
> After some debugging, I found the error:
> 
>  cut =
> ipa : DEBUGstderr=
> ipa.ipapython.dnssec.bindmgr.BINDMgr: INFO attrs: {'idnsseckeyref':
> ['pkcs11:object=a1'], 'dn':
> 'cn=KSK-2014073634Z-a1,cn=keys,idnsname=myzone.com.,cn=dns,dc=int,dc=gtrs,dc=de',
> 'cn': ['KSK-2014073634Z-a1'], 'idnsseckeypublish':
> ['2014073634Z'], 'objectclass': ['idnsSecKey'], 'idnsseckeysep':
> ['TRUE'], 'idnssecalgorithm': ['RSASHA1NSEC3SHA1'], 'idnsseckeyzone':
> ['TRUE'], 'idnsseckeycreated': ['2014073634Z'],
> 'idnsseckeyactivate': ['2014073634Z']}
> ipa : DEBUGStarting external process
> ipa : DEBUGargs=/usr/sbin/dnssec-keyfromlabel-pkcs11 -K
> /var/named/dyndb-ldap/ipa/master/myzone.com/tmp5dI2FC -a
> RSASHA1NSEC3SHA1 -l
> pkcs11:object=a1;pin-source=/var/lib/ipa/dnssec/softhsm_pin -I none
> -D none -P 2014073634 -A 2014073634 -f KSK myzone.com.
> ipa : DEBUGProcess finished, return code=1
> ipa : DEBUGstdout=
> ipa : DEBUGstderr=dnssec-keyfromlabel: fatal: unknown
> algorithm RSASHA1NSEC3SHA1
> 
> Traceback (most recent call last):
>   File "/usr/libexec/ipa/ipa-dnskeysyncd", line 112, in 
> while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
>   File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 409,
> in syncrepl_poll
> self.syncrepl_refreshdone()
>   File "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py",
> line 118, in syncrepl_refreshdone
> self.bindmgr.sync(self.dnssec_zones)
>   File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
> line 209, in sync
> self.sync_zone(zone)
>   File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
> line 182, in sync_zone
> self.install_key(zone, uuid, attrs, tempdir)
>   File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
> line 117, in install_key
> result = ipautil.run(cmd, capture_output=True)
>   File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line
> 479, in run
> raise CalledProcessError(p.returncode, arg_string, str(output))
> subprocess.CalledProcessError: Command
> '/usr/sbin/dnssec-keyfromlabel-pkcs11 -K
> /var/named/dyndb-ldap/ipa/master/myzone.com/tmp5dI2FC -a
> RSASHA1NSEC3SHA1 -l
> pkcs11:object=a1;pin-source=/var/lib/ipa/dnssec/softhsm_pin -I none
> -D none -P 2014073634 -A 2014073634 -f KSK myzone.com.' returned
> non-zero exit status 1
>  cut =
> 
> dnssec-keyfromlabel-pkcs11 expects NSEC3RSASHA1 for algorithm 7, but it
> gets RSASHA1NSEC3SHA1 instead (just the plain attribute value from LDAP).
> 
> I've changed a few lines in
> /usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py in method
> install_key:
> 
>  cut 
> 108c108,112
> < cmd = [paths.DNSSEC_KEYFROMLABEL, '-K', workdir, '-a',
> attrs['idnsSecAlgorithm'][0], '-l', uri]
> ---
>> algo = attrs['idnsSecAlgorithm'][0]
>> if algo == 'RSASHA1NSEC3SHA1':
>>  algo = 'NSEC3RSASHA1'
>> cmd = [paths.DNSSEC_KEYFROMLABEL, '-K', workdir, '-a', algo,
> '-l', uri]
>  cut 
> 
> Now, everything seems to work correctly: The DNSKEY records are
> published with the correct algorithms and the ZSK is signed by both KSKs
> (the imported one and the IPA generated one).

I'm glad it finally works!

For this particular problem I've created ticket
https://fedorahosted.org/freeipa/ticket/6229
so we can fix it independently on key import feature.

Thank you *very* much for your effort, it is very valuable experience and it
will help to improve FreeIPA!

-- 
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] replica_generate_next_csn messages in dirsrv error logs

[Ludwig Krispenz]

On 08/17/2016 08:54 PM, John Desantis wrote:

Hello all,

We've been re-using old host names and IP addresses for a new
deployment of nodes, and recently I've been seeing the messages pasted
below in the slapd-DC.DC.DC "error" log on our nodes.

[17/Aug/2016:10:30:30 -0400] - replica_generate_next_csn:
opcsn=57b475cd00120004 <= basecsn=57b475cf0016, adjusted
opcsn=57b475cf00010004
[17/Aug/2016:11:09:44 -0400] - replica_generate_next_csn:
opcsn=57b47f020004 <= basecsn=57b47f020016, adjusted
opcsn=57b47f030004
[17/Aug/2016:11:09:44 -0400] - replica_generate_next_csn:
opcsn=57b47f040004 <= basecsn=57b47f040016, adjusted
opcsn=57b47f050004
[17/Aug/2016:11:10:33 -0400] - replica_generate_next_csn:
opcsn=57b47f2f0014 <= basecsn=57b47f320016, adjusted
opcsn=57b47f330004
[17/Aug/2016:13:50:45 -0400] - replica_generate_next_csn:
opcsn=57b4a4bb00090004 <= basecsn=57b4a4bc0016, adjusted
opcsn=57b4a4bc00010004
[17/Aug/2016:13:52:54 -0400] - replica_generate_next_csn:
opcsn=57b4a53e000a0004 <= basecsn=57b4a53f0016, adjusted
opcsn=57b4a53f00010004
[17/Aug/2016:13:53:15 -0400] - replica_generate_next_csn:
opcsn=57b4a55200070004 <= basecsn=57b4a5530016, adjusted
opcsn=57b4a55300010004
[17/Aug/2016:13:53:32 -0400] - replica_generate_next_csn:
opcsn=57b4a56200090004 <= basecsn=57b4a5640016, adjusted
opcsn=57b4a56400010004
Each modification (add/del/mod) gets a csn assignged used in replication 
update resolution. And each assigned csn has to newer than an existing 
one. The messages you see is from code that double checks that the entry 
doesn't have already a lareg csn - and adjusts it.
The logs indicate that entries are more or less concurrently updated on 
replica 4 and 16, and the updates from16 are received while processing 
the updates on 4.
This is a normal scenario, but you could check if the simultaneous 
updates on 4 and 16 are intentional.


They seem to only occur when updating DNS entries, whether on the
console or via the GUI (tail -f'ing the log).

A search in this mailing-list returns nothing, but a message is found
on the 389-ds list [1];  it seems to suggest that the messages aren't
fatal and are purely informational, yet if they are occurring
constantly that there could be a problem with the replication
algorithm and/or deployment.

We're using ipa-server 3.0.0-47 and 389-ds 1.2.11.15-60.  Nothing has
changed on the deployment side of things, and I don't recall seeing
this message before.

I'm wondering if it's safe to disregard these messages due to the
re-use of the entries, or if something else should be looked into.

Thank you,
John DeSantis

[1] https://fedorahosted.org/389/ticket/47959



--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

--
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-cert-agent, Object Signing Cert certificate renewal

[realstarhealer]

Hi,

I am in charge for a freeipa 4.1.0.18.el7 server with ldap backend and noticed 
some expired certificates recently. Most of them but 2 are auto-renewing by 
certmonger as I checked. All of them are self signed.

"CN=ipa-ca-agent" and "CN=Object Signing Cert" are not subscribed by 
certmonger, ipa-ca-agent expired some days ago and has not been renewed. Second 
one expires soon. No consequences noticed so far.

Can you tell me what they both are for and - if needed - how I should renew 
that separately? Preferable with certmonger. An Output how the tracking config 
should look like would be nice.
Thanks a lot.  Vitali
-- 
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