[Freeipa-users] Re: Can't Add Replica: The changelog directory CLDB already exists and is not empty

2020-07-07 Thread Florence Blanc-Renaud via FreeIPA-users 

On 7/7/20 10:13 PM, Andrey Ptashnik via FreeIPA-users wrote:

Team,

I'm trying to install FreeIPA replica and constantly hitting this error below.
OS where replica is being installed is a fresh install. IPA version 4.6.6
After this error Master does not have any record of replica anyway.

Can someone please shed some light why on the machine with fresh OS install I can see 
error such "directory [/var/lib/dirsrv/slapd-EXAMPLE-COM/cldb] already exists and is 
not empty"

Command that I'm using from a client machine that is already in the domain:

[root@server-02] #  kinit admin
[root@server-02] # ipa-replica-install --server server-01.example.com --domain 
example.com --setup-dns --setup-ca --forwarder 10.1xx.1xx.10
---8<--8<--8<--8<--8<--8<--8<--8<---
   [28/42]: ignore time skew for initial replication
   [29/42]: setting up initial replication
   [error] DatabaseError: Operations error: The changelog directory 
[/var/lib/dirsrv/slapd-EXAMPLE-COM/cldb] already exists and is not empty.  
Please choose a directory that does not exist or is empty.
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
---8<--8<--8<--8<--8<--8<--8<--8<---


Hi,

it looks like the machine was already configured as a replica.

Please run ipa-server-install --uninstall -U on the soon-to-be replica, 
check that there is no /var/lib/dirsrv/slapd-EXAMPLE-COM directory, and 
re-try with ipa-client-install and ipa-replica-install.


flo

Regards,
  
Andrey
  



___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Adding new replica with CA fails.

2020-07-07 Thread Guillermo Fuentes via FreeIPA-users 
Confirmed Fraser. It worked! Thanks so much!
Using the decimal value in the nextRange attribute did the trick.
Thank you everyone for your help.
All the best,
Guillermo

On Tue, Jul 7, 2020 at 3:57 AM Fraser Tweedale  wrote:
>
> On Tue, Jul 07, 2020 at 12:04:58AM -0400, Guillermo Fuentes via FreeIPA-users 
> wrote:
> > On Mon, Jul 6, 2020 at 5:31 PM Rob Crittenden  wrote:
> > >
> > > Guillermo Fuentes via FreeIPA-users wrote:
> > > > Hi Flo,
> > > > Here is the value of the entry:
> > > > # certificateRepository, ca, ipaca
> > > > dn: ou=certificateRepository,ou=ca,o=ipaca
> > > > objectClass: top
> > > > objectClass: repository
> > > > ou: certificateRepository
> > > > serialno: 09268369921
> > > > nextRange: e001
> > > >
> > > > The value of nextRange was modified by hand to fix another issue.
> > > > According to this
> > > > https://frasertweedale.github.io/blog-redhat/posts/2019-07-26-dogtag-replica-ranges.html
> > > > it should be hexadecimal.
> > >
> > > Maybe try an upper-case E.
> > >
> > > rob
> >
> > Same result.
> >
> IIRC the ldap objects all use decimal representation.  It is only in
> CS.cfg where some ranges are hexadecimal and others are decimal.
> I can confirm later.  And update the blog post to clarify!
>
> Put the decimal representation in the `nextRange' attribute and see
> how you go.
>
> Cheers,
> Fraser
>
>
> > >
> > > >
> > > > If the code is expecting a decimal value, I'm assuming converting the
> > > > range from hex to decimal should do it, right? I'll also check for
> > > > conflicts.
> > > >
> > > > Thanks!
> > > > Guillermo
> > > >
> > > > On Mon, Jul 6, 2020 at 12:35 PM Florence Blanc-Renaud  
> > > > wrote:
> > > >>
> > > >> On 7/6/20 5:18 PM, Guillermo Fuentes via FreeIPA-users wrote:
> > > >>> Hi all,
> > > >>>
> > > >>> I'm having an issue creating a new replica with CA.
> > > >>> The Directory Service installation works fine but adding the CA clone
> > > >>> fails with a java.lang.NumberFormatException when getting the serial
> > > >>> number range.
> > > >>>
> > > >>> This is the error logged in /var/log/pki/pki-tomcat/ca/debug:
> > > >>> ##
> > > >>> ...
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: retrieving
> > > >>> ou=ca, ou=requests,o=ipaca
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: updating
> > > >>> nextRange from 8001 to 9001
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: adding new
> > > >>> range object: cn=8001,ou=requests, ou=ranges,o=ipaca
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem:
> > > >>> getNextRange  Next range has been added: 8001 - 9000
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Releasing ldap 
> > > >>> connection
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: returnConn: mNumConns 
> > > >>> now 3
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: next 
> > > >>> range: 8001
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Next min
> > > >>> serial number: 8001
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: Setting
> > > >>> next min requests number: 8001
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: Setting
> > > >>> next max requests number: 9000
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Checking for a range 
> > > >>> conflict
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: In
> > > >>> LdapBoundConnFactory::getConn()
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: masterConn is 
> > > >>> connected: true
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: conn is 
> > > >>> connected true
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: mNumConns now 
> > > >>> 2
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Releasing ldap 
> > > >>> connection
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: returnConn: mNumConns 
> > > >>> now 3
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: CMSEngine: checking
> > > >>> certificate serial number ranges
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Serial
> > > >>> numbers left in range: 65536
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Last serial
> > > >>> number: 2415656960
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Serial
> > > >>> numbers available: 65536
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Low water
> > > >>> mark: 33554432
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Requesting 
> > > >>> next range
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: In
> > > >>> LdapBoundConnFactory::getConn()
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: masterConn is 
> > > >>> connected: true
> > > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: conn is 
> > > >>> connected true
> > > >>>

[Freeipa-users] Can't Add Replica: The changelog directory CLDB already exists and is not empty

2020-07-07 Thread Andrey Ptashnik via FreeIPA-users 
Team,

I'm trying to install FreeIPA replica and constantly hitting this error below.
OS where replica is being installed is a fresh install. IPA version 4.6.6
After this error Master does not have any record of replica anyway.

Can someone please shed some light why on the machine with fresh OS install I 
can see error such "directory [/var/lib/dirsrv/slapd-EXAMPLE-COM/cldb] already 
exists and is not empty"

Command that I'm using from a client machine that is already in the domain:

[root@server-02] #  kinit admin
[root@server-02] # ipa-replica-install --server server-01.example.com --domain 
example.com --setup-dns --setup-ca --forwarder 10.1xx.1xx.10
---8<--8<--8<--8<--8<--8<--8<--8<---
  [28/42]: ignore time skew for initial replication
  [29/42]: setting up initial replication
  [error] DatabaseError: Operations error: The changelog directory 
[/var/lib/dirsrv/slapd-EXAMPLE-COM/cldb] already exists and is not empty.  
Please choose a directory that does not exist or is empty.
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
---8<--8<--8<--8<--8<--8<--8<--8<---

Regards,
 
Andrey
 

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Plans for integrating DHCP

2020-07-07 Thread Vinícius Ferrão via FreeIPA-users 
It may seem out of scope, and I agree with this.

But IMHO it should have a better integration with DHCP. Look at MS Active 
Directory, it’s so deeply integrated with MS DHCP that you just install it as 
an add-on. The same thing does not happen on IPA. A better integration would be 
extremely good for FreeIPA; for sure there are guides to better integrate ISC 
DHCP, but some things are lacking, like better DDNS, RNDC keys, etc.

Storing DHCP leases on LDAP is an extra, it may be out of scope, as you said. 
But to achieve this I think other issues should be resolved first and in fact 
they don’t seem to be out of scope.

Again, this is my opinion, just as a FreeIPA “consumer”.

On 7 Jul 2020, at 15:33, Nicholas DeMarco via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

DHCP seems out of scope for IPA.

On Wed, Jun 3, 2020 at 9:17 AM lejeczek via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:


On 24/04/2020 11:44, Alexander Bokovoy via FreeIPA-users wrote:
> On pe, 24 huhti 2020, Ronald Wimmer via FreeIPA-users wrote:
>> Hi there,
>>
>> are there any plans to integrate a DHCP server into
>> FreeIPA. We have several environments where a lack of
>> DHCP is a showstopper at the moment.
>
> No official plans yet. However, there is a draft version
> at https://github.com/cabeljunky/freeipa-plugin-dhcp which
> seems to work
> for some people.
>
> Couple weeks ago I started to rewrite that plugin to
> follow FreeIPA code
> standards but haven't yet reached a point where I have
> anything working
> yet. It is done at my own time, when it is available.
>
>
Yes, it would be utterly fantastic and make freeIPA even
more complete solution if DHCP was integrated.

As of now there is not some semi/official guide to set DHCP
to IPA's dirsrv, or is there?

many thanks, L.
___
FreeIPA-users mailing list -- 
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- 
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Plans for integrating DHCP

2020-07-07 Thread Nicholas DeMarco via FreeIPA-users 
DHCP seems out of scope for IPA.

On Wed, Jun 3, 2020 at 9:17 AM lejeczek via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

>
>
> On 24/04/2020 11:44, Alexander Bokovoy via FreeIPA-users wrote:
> > On pe, 24 huhti 2020, Ronald Wimmer via FreeIPA-users wrote:
> >> Hi there,
> >>
> >> are there any plans to integrate a DHCP server into
> >> FreeIPA. We have several environments where a lack of
> >> DHCP is a showstopper at the moment.
> >
> > No official plans yet. However, there is a draft version
> > at https://github.com/cabeljunky/freeipa-plugin-dhcp which
> > seems to work
> > for some people.
> >
> > Couple weeks ago I started to rewrite that plugin to
> > follow FreeIPA code
> > standards but haven't yet reached a point where I have
> > anything working
> > yet. It is done at my own time, when it is available.
> >
> >
> Yes, it would be utterly fantastic and make freeIPA even
> more complete solution if DHCP was integrated.
>
> As of now there is not some semi/official guide to set DHCP
> to IPA's dirsrv, or is there?
>
> many thanks, L.
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Adding Windows 10 client to freeIPA - Error : Failed to parse result: All enctypes provided are unsupported

2020-07-07 Thread Alexander Bokovoy via FreeIPA-users 

On ti, 07 heinä 2020, lovepreetdeol via FreeIPA-users wrote:

Hi,
Running freeIPA server on centos 8.2. Trying to setup mixed OS
environment with linux and windows clients.  Another centos8.2 machine
connects to freeIPA without any problem.
I am trying to connect a windows 10 client to the freeIPA and getting
the following error :


This (enrolling Windows system to IPA) is not supported. 


Your problem is different, though.


[root@directory ~]#
[root@directory ~]# ipa-getkeytab -s directory.compnet.local -p 
host/win10.compnet.local -e arcfour-hmac -k krb5.keytab.win10 -P
New Principal Password:
Verify Principal Password:
Failed to parse result: All enctypes provided are unsupported
Retrying with pre-4.0 keytab retrieval method...
Failed to parse result: All enctypes provided are unsupported
Failed to get keytab!
Failed to get keytab
[root@directory ~]#


In RHEL 8.2 (and earlier, starting with Fedora 30) MIT Kerberos started
to deprecate RC4-HMAC encryption type. It is weak. FreeIPA 4.8.2+
changed the code to prevent generation of RC4-HMAC keys for all
principals but cifs/..., so this is what you see above.

https://freeipa.readthedocs.io/en/latest/designs/adtrust/samba-domain-controller.html#changes-to-ldap-plugins

This is also documented in RHEL 8 documentation:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_identity_management/index#enabling-the-aes-encryption-type-in-active-directory-using-a-gpo_setting-up-samba-on-an-idm-domain-member


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Plans for integrating DHCP

2020-07-07 Thread Uzor Ide via FreeIPA-users 
Take a look at this implementation. I may be old but could give an idea on
how to proceed
https://github.com/Turgon37/freeipa-plugin-dhcp


On Mon, Jul 6, 2020 at 1:39 PM Charles Hedrick via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> hmmm. so the problem with our integration is that we use the standard
> schema. that makes DHCP data a separate tree. To make it a real part of
> freeipa you’d want to get data for a  host from its normal host entry.
> Either you’d need to modify the server to read data from the normal freeipa
> data, or you could keep the official DHCP schema, but make the management
> tools see the items as attributes of the freeipa host entry. Both are
> pretty easy to do. But I can see that a real integration like this would be
> a project that would compete with other priorities for IPA.
>
> From my point of view, it’s kind of the biggest missing piece in IPA at
> the moment, though our integration works fine and shouldn’t present any
> maintenance issues.
>
> (You may ask, why use IPA for your DHCP data? In our case it’s because IPA
> is the only multimaster replicated data we have. I’d rather not have to
> manage a mulitimasteir SQL database just to do DHCP.)
>
>
> > On Jul 6, 2020, at 2:24:43 PM, Charles Hedrick via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> >
> > The main issues are
> > * adding to the schema
> > * tools for managing
> > * dynamic address allocation
> >
> > We don’t use dynamic allocation. so that’s not an issue for us. That
> means the normal ISC dhcpd works fine. It supports getting data from LDAP.
> They supply a schema file, which with some tweaking works fine with freeipa.
> >
> > I have a .py file that will add commands to the IPA command line to
> manage most data. That should work anywhere with possible minor changes
> because the base DN will not be Rutgers. I also have a web GUI which is
> part of my larger user management system. That might be a bit harder to
> port, though in principle the whole system is designed to be portable. (It
> uses Spring Boot.)
> >
> > The issues I see with integration into freeipa are
> > * adding it to the freeipa web GUI. I think that can be done with their
> defined extension method, so it doesn’t need a change in core code
> > * dynamic address management.
> >
> > The current ISC daemon uses a master / backup approach for dynamic
> address allocation. So it stores allocations locally on the server. That
> means it doesn’t need LDAP or another database. It should work just fine
> with freeipa. However the newer ISC DHCP code (currently a separate
> project) really wants a symmetrical database. LDAP might work, depending
> upon how often you need to allocate addresses, but LDAP really isn’t
> intended for high write rates.
> >
> >> On Apr 24, 2020, at 6:23 AM, Ronald Wimmer via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> >>
> >> Hi there,
> >>
> >> are there any plans to integrate a DHCP server into FreeIPA. We have
> several environments where a lack of DHCP is a showstopper at the moment.
> >>
> >> Cheers,
> >> Ronald
> >> ___
> >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> >> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.org
> >> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Adding Windows 10 client to freeIPA - Error : Failed to parse result: All enctypes provided are unsupported

2020-07-07 Thread Rob Crittenden via FreeIPA-users 
lovepreetdeol via FreeIPA-users wrote:
> Hi, 
> Running freeIPA server on centos 8.2. Trying to setup mixed OS environment 
> with linux and windows clients. 
> Another centos8.2 machine connects to freeIPA without any problem.
> I am trying to connect a windows 10 client to the freeIPA and getting the 
> following error :
> 
> [root@directory ~]# 
> [root@directory ~]# ipa-getkeytab -s directory.compnet.local -p 
> host/win10.compnet.local -e arcfour-hmac -k krb5.keytab.win10 -P
> New Principal Password: 
> Verify Principal Password: 
> Failed to parse result: All enctypes provided are unsupported
> Retrying with pre-4.0 keytab retrieval method...
> Failed to parse result: All enctypes provided are unsupported
> Failed to get keytab!
> Failed to get keytab
> [root@directory ~]# 
> 
> References followed :
> https://www.rootusers.com/how-to-login-to-windows-with-a-freeipa-account/  
> https://www.freeipa.org/page/Windows_authentication_against_FreeIPA 
> https://www.server-world.info/en/note?os=CentOS_7=ipa=8

RC4 ciphers are no longer allowed. Drop the -e arcfour-hmac and you
might get farther.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Adding Windows 10 client to freeIPA - Error : Failed to parse result: All enctypes provided are unsupported

2020-07-07 Thread lovepreetdeol via FreeIPA-users 
Hi, 
Running freeIPA server on centos 8.2. Trying to setup mixed OS environment with 
linux and windows clients. 
Another centos8.2 machine connects to freeIPA without any problem.
I am trying to connect a windows 10 client to the freeIPA and getting the 
following error :

[root@directory ~]# 
[root@directory ~]# ipa-getkeytab -s directory.compnet.local -p 
host/win10.compnet.local -e arcfour-hmac -k krb5.keytab.win10 -P
New Principal Password: 
Verify Principal Password: 
Failed to parse result: All enctypes provided are unsupported
Retrying with pre-4.0 keytab retrieval method...
Failed to parse result: All enctypes provided are unsupported
Failed to get keytab!
Failed to get keytab
[root@directory ~]# 

References followed :
https://www.rootusers.com/how-to-login-to-windows-with-a-freeipa-account/  
https://www.freeipa.org/page/Windows_authentication_against_FreeIPA 
https://www.server-world.info/en/note?os=CentOS_7=ipa=8

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Kerberos realm trusting ipa realm

2020-07-07 Thread Alexander Bokovoy via FreeIPA-users 

On ti, 07 heinä 2020, Gerald Vogt via FreeIPA-users wrote:

On 07.07.20 10:13, Alexander Bokovoy wrote:

On ti, 07 heinä 2020, Gerald Vogt via FreeIPA-users wrote:

Hi!

I am trying to get a kerberos realm to trust the ipa realm. I'm running
ipa-server-4.6.6-11.el7 on a CentOS 7. It uses realm IPA.EXAMPLE.COM.

I have another KDC on another CentOS 7 which has another realm
KRB.EXAMPLE.COM with a legacy service connected.

Now I would like all users of my IPA realm to use that legacy service.
Thus I need the KRB realm to trust the IPA realm. I don't need the IPA
realm to trust the KRB realm.

For the KRB KDC I have no problem adding the necessary
krbtgt/krb.example@ipa.example.com principal with a password.

However, everything I find about adding it to the IPA Kerberos involves
kadmin.local which seems not to be supported anymore:

kadmin.local: Cannot open DB2 database
'/var/kerberos/krb5kdc/principal': No such file or directory while
initializing kadmin.local interface


The message above says that DB2 database driver is used by kadmin.local
instead of IPA one. Your /etc/krb5.conf should have:

[dbmodules]
   IPA.TEST = {
 db_library = ipadb.so
   }


Thanks. I have missed that.


How do I add this principal correctly to my IPA kerberos? Is it
possible?


Kind of. Beware of dragons, of course.

WARNING: this is not supported for mindless enablement. If you'd break
your system, it is all your fault.

You need to use '-x ipa-setup-override-restrictions' to kadmin.local
when it uses ipadb module.

Please note that FreeIPA expectation from trusted realms are stricter
than in a standard MIT KDC case. For example, if your trusted realm
produces PAC records in the tickets, these tickets will be rejected if
FreeIPA KDC cannot find corresponding trusted domain definition in IPA
LDAP. This, for example, is not possible right now for IPA-IPA trust.

A non-AD-compatible Kerberos realm can be made trusted but that's about
it. If it has user principals that couldn't be mapped to IPA users, the
only thing that those principals would be able to do is to obtain
service tickets to IPA services. They would not exist on POSIX level, of
course, so none of POSIX-specific operations would work, including HBAC
rules.


O.K. Now you have got me confused. I thought, all I needed was for my
KRB realm to trust the IPA realm and not vice versa. Thus, all I needed
was the principal in the IPA kerberos. I don't want the IPA realm to
trust the KRB realm. Only the IPA users are supposed to access the KRB
realm service using kerberos.

It's my understanding that your remarks in your two last paragraphs
don't apply here. Or am I missing something?


No, you are good -- I tried to structure my answer to also make sure
people don't try it the other way around as a supported solution. ;)


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Kerberos realm trusting ipa realm

2020-07-07 Thread Gerald Vogt via FreeIPA-users 
On 07.07.20 10:13, Alexander Bokovoy wrote:
> On ti, 07 heinä 2020, Gerald Vogt via FreeIPA-users wrote:
>> Hi!
>>
>> I am trying to get a kerberos realm to trust the ipa realm. I'm running
>> ipa-server-4.6.6-11.el7 on a CentOS 7. It uses realm IPA.EXAMPLE.COM.
>>
>> I have another KDC on another CentOS 7 which has another realm
>> KRB.EXAMPLE.COM with a legacy service connected.
>>
>> Now I would like all users of my IPA realm to use that legacy service.
>> Thus I need the KRB realm to trust the IPA realm. I don't need the IPA
>> realm to trust the KRB realm.
>>
>> For the KRB KDC I have no problem adding the necessary
>> krbtgt/krb.example@ipa.example.com principal with a password.
>>
>> However, everything I find about adding it to the IPA Kerberos involves
>> kadmin.local which seems not to be supported anymore:
>>
>> kadmin.local: Cannot open DB2 database
>> '/var/kerberos/krb5kdc/principal': No such file or directory while
>> initializing kadmin.local interface
> 
> The message above says that DB2 database driver is used by kadmin.local
> instead of IPA one. Your /etc/krb5.conf should have:
> 
> [dbmodules]
>IPA.TEST = {
>  db_library = ipadb.so
>}

Thanks. I have missed that.

>> How do I add this principal correctly to my IPA kerberos? Is it
>> possible?
> 
> Kind of. Beware of dragons, of course.
> 
> WARNING: this is not supported for mindless enablement. If you'd break
> your system, it is all your fault.
> 
> You need to use '-x ipa-setup-override-restrictions' to kadmin.local
> when it uses ipadb module.
> 
> Please note that FreeIPA expectation from trusted realms are stricter
> than in a standard MIT KDC case. For example, if your trusted realm
> produces PAC records in the tickets, these tickets will be rejected if
> FreeIPA KDC cannot find corresponding trusted domain definition in IPA
> LDAP. This, for example, is not possible right now for IPA-IPA trust.
> 
> A non-AD-compatible Kerberos realm can be made trusted but that's about
> it. If it has user principals that couldn't be mapped to IPA users, the
> only thing that those principals would be able to do is to obtain
> service tickets to IPA services. They would not exist on POSIX level, of
> course, so none of POSIX-specific operations would work, including HBAC
> rules.

O.K. Now you have got me confused. I thought, all I needed was for my KRB realm 
to trust the IPA realm and not vice versa. Thus, all I needed was the principal 
in the IPA kerberos. I don't want the IPA realm to trust the KRB realm. Only 
the IPA users are supposed to access the KRB realm service using kerberos.

It's my understanding that your remarks in your two last paragraphs don't apply 
here. Or am I missing something?

Thx,

Gerald
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Providing service level access without granting sudo access

2020-07-07 Thread Alexander Bokovoy via FreeIPA-users 

On ti, 07 heinä 2020, Saurabh Garg via FreeIPA-users wrote:

Hi All,

We have a requirement where we need to give a user access to stop and
start a service like tomcat8 without giving sudo access on that
machine.

I tried adding tomcat8 service (running on an ubuntu host) on the Idm
server using "ipa service-add" command. Later, when I tried creating a
hbac policy to provide access to a user on that service, it doesn't
show up. Is there any other way of providing service level access to a
user on Redhat IdM?


Your first mistake is by mixing Kerberos services and HBAC services.
HBAC service is a name for PAM service configuration file, /etc/pam.d/.
HBAC rules define access to an application that uses a specific PAM
service  to identify itself when using PAM stack.

Kerberos service is unrelated to that, completely.

Now, from what you described, you want to allow a user to run

 systemctl start|stop|status tomcat8.service

without the user being root. Could you please confirm this?

The interaction between unprivileged user and systemd requires raise of
privileges. systemd uses polkit for this purpose and all collection of
enabled polkit rules consulted. If I'd try to run

  systemctl stop sssd

as non-privileged user, I can see an authorization dialog popping up on
my screen and the following in the journal when I cancel the dialog:

polkitd[955]: Operator of unix-session:2 FAILED to authenticate to gain authorization 
for action org.freedesktop.systemd1.manage-units for system-bus-name::1.2077 
[systemctl stop sssd] (owned by unix-user:)

The request is evaluated by polkit rules and this is where you can
affect the decision. For example, like these people did it:
https://unix.stackexchange.com/questions/595207/polkit-rule-for-systemd-template-files-how-to

Quite a few years ago a similar rule was created by Adam Williamson in
his blog: 
https://www.happyassassin.net/posts/2014/09/09/freeipa-setting-polkit-policykit-rules-for-users-make-your-user-a-polkit-administrator-on-your-clients/

Note the difference: Adam's blog uses addAdminRule() while the
stackexchange's answer uses addRule(). Both described here:
https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
and they have different return values.

If you look at the polkit documentation, it has few examples. One
example shows that 'subject' argument to the function defined in
addRule() is an object with a number of methods. One method it has is
inGroup(). This method checks whether a specific user belongs to a POSIX
groups with the name.

So you can combine this information by doing a check for a service name
and a POSIX group this user belongs to. For example:

polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units" &&
RegExp('tomcat8@[A-Za-z0-9_-]+.service').test(action.lookup("unit")) === true 
&&
subject.inGroup("tomcat-admins")) {
return polkit.Result.YES;
}
});

Sadly, there is no way to directly use HBAC rules for this, save for
using 'polkit.spawn()' method and run some helper that would do PAM
authorization.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Kerberos realm trusting ipa realm

2020-07-07 Thread Alexander Bokovoy via FreeIPA-users 

On ti, 07 heinä 2020, Gerald Vogt via FreeIPA-users wrote:

Hi!

I am trying to get a kerberos realm to trust the ipa realm. I'm running
ipa-server-4.6.6-11.el7 on a CentOS 7. It uses realm IPA.EXAMPLE.COM.

I have another KDC on another CentOS 7 which has another realm
KRB.EXAMPLE.COM with a legacy service connected.

Now I would like all users of my IPA realm to use that legacy service.
Thus I need the KRB realm to trust the IPA realm. I don't need the IPA
realm to trust the KRB realm.

For the KRB KDC I have no problem adding the necessary
krbtgt/krb.example@ipa.example.com principal with a password.

However, everything I find about adding it to the IPA Kerberos involves
kadmin.local which seems not to be supported anymore:

kadmin.local: Cannot open DB2 database
'/var/kerberos/krb5kdc/principal': No such file or directory while
initializing kadmin.local interface


The message above says that DB2 database driver is used by kadmin.local
instead of IPA one. Your /etc/krb5.conf should have:

[dbmodules]
  IPA.TEST = {
db_library = ipadb.so
  }




How do I add this principal correctly to my IPA kerberos? Is it
possible?


Kind of. Beware of dragons, of course.

WARNING: this is not supported for mindless enablement. If you'd break
your system, it is all your fault.

You need to use '-x ipa-setup-override-restrictions' to kadmin.local
when it uses ipadb module.

Please note that FreeIPA expectation from trusted realms are stricter
than in a standard MIT KDC case. For example, if your trusted realm
produces PAC records in the tickets, these tickets will be rejected if
FreeIPA KDC cannot find corresponding trusted domain definition in IPA
LDAP. This, for example, is not possible right now for IPA-IPA trust.

A non-AD-compatible Kerberos realm can be made trusted but that's about
it. If it has user principals that couldn't be mapped to IPA users, the
only thing that those principals would be able to do is to obtain
service tickets to IPA services. They would not exist on POSIX level, of
course, so none of POSIX-specific operations would work, including HBAC
rules.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Providing service level access without granting sudo access

2020-07-07 Thread Saurabh Garg via FreeIPA-users 
Hi All,

We have a requirement where we need to give a user access to stop and start a 
service like tomcat8 without giving sudo access on that machine.

I tried adding tomcat8 service (running on an ubuntu host) on the Idm server 
using "ipa service-add" command. Later, when I tried creating a hbac policy to 
provide access to a user on that service, it doesn't show up. Is there any 
other way of providing service level access to a user on Redhat IdM?

Please advice.


Thanks,
Saurabh Garg
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Adding new replica with CA fails.

2020-07-07 Thread Fraser Tweedale via FreeIPA-users 
On Tue, Jul 07, 2020 at 12:04:58AM -0400, Guillermo Fuentes via FreeIPA-users 
wrote:
> On Mon, Jul 6, 2020 at 5:31 PM Rob Crittenden  wrote:
> >
> > Guillermo Fuentes via FreeIPA-users wrote:
> > > Hi Flo,
> > > Here is the value of the entry:
> > > # certificateRepository, ca, ipaca
> > > dn: ou=certificateRepository,ou=ca,o=ipaca
> > > objectClass: top
> > > objectClass: repository
> > > ou: certificateRepository
> > > serialno: 09268369921
> > > nextRange: e001
> > >
> > > The value of nextRange was modified by hand to fix another issue.
> > > According to this
> > > https://frasertweedale.github.io/blog-redhat/posts/2019-07-26-dogtag-replica-ranges.html
> > > it should be hexadecimal.
> >
> > Maybe try an upper-case E.
> >
> > rob
> 
> Same result.
> 
IIRC the ldap objects all use decimal representation.  It is only in
CS.cfg where some ranges are hexadecimal and others are decimal.
I can confirm later.  And update the blog post to clarify!

Put the decimal representation in the `nextRange' attribute and see
how you go.

Cheers,
Fraser


> >
> > >
> > > If the code is expecting a decimal value, I'm assuming converting the
> > > range from hex to decimal should do it, right? I'll also check for
> > > conflicts.
> > >
> > > Thanks!
> > > Guillermo
> > >
> > > On Mon, Jul 6, 2020 at 12:35 PM Florence Blanc-Renaud  
> > > wrote:
> > >>
> > >> On 7/6/20 5:18 PM, Guillermo Fuentes via FreeIPA-users wrote:
> > >>> Hi all,
> > >>>
> > >>> I'm having an issue creating a new replica with CA.
> > >>> The Directory Service installation works fine but adding the CA clone
> > >>> fails with a java.lang.NumberFormatException when getting the serial
> > >>> number range.
> > >>>
> > >>> This is the error logged in /var/log/pki/pki-tomcat/ca/debug:
> > >>> ##
> > >>> ...
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: retrieving
> > >>> ou=ca, ou=requests,o=ipaca
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: updating
> > >>> nextRange from 8001 to 9001
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: adding new
> > >>> range object: cn=8001,ou=requests, ou=ranges,o=ipaca
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem:
> > >>> getNextRange  Next range has been added: 8001 - 9000
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Releasing ldap connection
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: returnConn: mNumConns 
> > >>> now 3
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: next range: 
> > >>> 8001
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Next min
> > >>> serial number: 8001
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: Setting
> > >>> next min requests number: 8001
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: Setting
> > >>> next max requests number: 9000
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Checking for a range 
> > >>> conflict
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: In
> > >>> LdapBoundConnFactory::getConn()
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: masterConn is connected: 
> > >>> true
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: conn is 
> > >>> connected true
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: mNumConns now 2
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Releasing ldap connection
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: returnConn: mNumConns 
> > >>> now 3
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: CMSEngine: checking
> > >>> certificate serial number ranges
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Serial
> > >>> numbers left in range: 65536
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Last serial
> > >>> number: 2415656960
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Serial
> > >>> numbers available: 65536
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Low water
> > >>> mark: 33554432
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Requesting 
> > >>> next range
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: In
> > >>> LdapBoundConnFactory::getConn()
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: masterConn is connected: 
> > >>> true
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: conn is 
> > >>> connected true
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: mNumConns now 2
> > >>> [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: retrieving
> > >>> ou=certificateRepository, ou=ca,o=ipaca
> > >> Hi,
> > >>
> > >> What is the content of this entry?
> > >> ldapsearch -D "cn=directory manager" -W -b
> > >> "ou=certificateRepository,ou=ca,o=ipaca" -s base
> > >>
> > >> According to the code, a decimal format is expected for the attribute
> > >> nextRange. Was the value modified by hand?

[Freeipa-users] Kerberos realm trusting ipa realm

2020-07-07 Thread Gerald Vogt via FreeIPA-users 
Hi!

I am trying to get a kerberos realm to trust the ipa realm. I'm running 
ipa-server-4.6.6-11.el7 on a CentOS 7. It uses realm IPA.EXAMPLE.COM.

I have another KDC on another CentOS 7 which has another realm KRB.EXAMPLE.COM 
with a legacy service connected.

Now I would like all users of my IPA realm to use that legacy service. Thus I 
need the KRB realm to trust the IPA realm. I don't need the IPA realm to trust 
the KRB realm.

For the KRB KDC I have no problem adding the necessary 
krbtgt/krb.example@ipa.example.com principal with a password.

However, everything I find about adding it to the IPA Kerberos involves 
kadmin.local which seems not to be supported anymore:

kadmin.local: Cannot open DB2 database '/var/kerberos/krb5kdc/principal': No 
such file or directory while initializing kadmin.local interface

How do I add this principal correctly to my IPA kerberos? Is it possible?

Thx.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org