[Freeipa-users] Integrating with NIS Domains and Netgroups

[Zhong Qiang]

hi,
I have some hosts installed centos4.8/6.5/5.9,and want to centralize
identity/policy/authorization.but ipa client isn't compatible with
centos4.8,so I try to configure FreeIPA integrated with NIS Domains.
 IPAserver:centos7 (+DNS)
 nisclient:centos4.8
  ipaclient:centos6.6

 I followed the instructions of this page:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/nis.html,to
add netgroup(nis_test) and users(zhongq).then configured nis client
installed centos4.8.on the nis client, I could get  users data ,look like
that:

[root@nisclient ~]# getent passwd zhongq
zhongq:*:72481:72481:强 é:/home/zhongq:/bin/sh


However,I do not succeed to log into nisclient with zhongq account.
Any ideas?

Regards,
zhongq
-- 
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] Multiple Domains and SSH

[Christoph Kaminski]

Hi

I can reach each host here via ssh on multiple domains:

host.mydom.int
host mydom.net
host.mgmt

sss_ssh_knownhostproxy does work only on the domain which I have use to 
register to ipa (mgmt), on the other domains I get ever "The authenticity 
of host 'host.mydom.int ()' can't be 
established."... why?

it is possible to make it working for the other domains to?

MfG
Christoph Kaminski


www.biotronik.com 
BIOTRONIK - excellence for life 
Established with the development of the first German pacemaker in 1963, 
BIOTRONIK has upheld the highest quality standards in the fields of cardiac 
rhythm management and vascular intervention in more than 100 countries 
worldwide. We’ve developed advanced technologies and products such as BIOTRONIK 
Home Monitoring®, Closed Loop Stimulation (CLS) and Orsiro, the industry’s 
first hybrid drug eluting stent. BIOTRONIK also offers the broadest portfolio 
of cardiac devices with ProMRI®, an advanced technology that gives patients 
access to magnetic resonance (MR) scanning. 
BIOTRONIK SE & Co. KG 
Woermannkehre 1, 12359 Berlin, Germany 
Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 

Vertreten durch ihre Komplementärin: 
BIOTRONIK MT SE 
Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B 
Geschäftsführende Direktoren: Christoph Böhmer, Dr. Lothar Krings 
This e-mail and the information it contains including attachments are 
confidential and meant only for use by the intended recipient(s); disclosure or 
copying is strictly prohibited. If you are not addressed, but in the possession 
of this e-mail, please notify the sender immediately and delete the document. -- 
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] Group membership not populated

[Jakub Hrozek]

On Mon, Nov 17, 2014 at 05:59:15PM +0100, Jakub Hrozek wrote:
> On Fri, Nov 14, 2014 at 04:30:17PM +, Darren Poulson wrote:
> > Ok,
> > 
> > I've shoved them on pastebin. They were a bit big to put in a mailing list 
> > really.
> > 
> > ldap_child.log: http://pastebin.com/qGCZF4vK
> > sssd_nss.log: http://pastebin.com/gTBA8NEj
> > sssd_bur.us.genops.log: http://pastebin.com/ithUqb1z
> 
> Seems like this is another instance of sssd_nss.log ?
> 
> > 
> > I did see this in the sssd_nss.log:
> > 
> > (Fri Nov 14 16:09:34 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got 
> > reply from Data Provider - DP error code: 3 errno: 17 error message: Init 
> > group lookup failed
> > (Fri Nov 14 16:09:34 2014) [sssd[nss]] [nss_cmd_getby_dp_callback] 
> > (0x0040): Unable to get information from Data Provider
> > Error: 3, 17, Init group lookup failed
> 
> Right, this is the problem. I'm not sure what's wrong, sssd domain log
> would tell us more..

Ah, sorry, I replied to your mail in my INBOX before seeing the rest of
the discussion on the list.

Happy it works now!

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

Re: [Freeipa-users] Questions about commande ipa user-add used to import NIS accounts

[Rob Crittenden]

Edouard Guigné wrote:
> Hello freeipa users
> 
> I followed the instructions of this page :
> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
> 
> in order to integrate NIS accounts over IPA with preserving passwords.
> 
> However, I do not succeed to import user as indicate on documentation :
> 
> # ipa user-add /user1/--setattr=userpassword={CRYPT}//
> return :
> *"ipa: ERROR: Constraint violation : invalid password syntax - passwords
> with storage scheme are not allowed"*
> 
> Someone could help ?

You enabled migration mode?

ipa config-mod --enable-migration=true

If you have, what version of IPA is this?

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] strange replica creation problem

[Rob Crittenden]

Janelle wrote:
> I did find that as the work-around - just trying to understand why it
> comes up sometimes...
> Did you find any issues with the workings of a replica if you had to
> resort to this method?

The conncheck is a reaction to a slew of problems people had setting up
replicas and because we don't have direct firewall integration. It
provides a way to detect errors that will eventually cause an
installation to fail. It isn't necessary to run which is why we provided
the skip option.

As for why the ssh fails, you'd need to check the system logs on the IPA
master where it is failing. The ssh is only used so we can test the
reverse connection, it isn't used once the installation itself starts.

rob

> 
> Thanks.
> 
> ~J
> 
> On 11/17/14 10:57 AM, Craig White wrote:
>>
>> Janelle, this may not be that useful but I found it worthwhile to
>> resort to…
>>
>>  
>>
>> –skip-conncheck
>>
>>  
>>
>> When setting up the replica – pretty much for the same reason.
>>
>>  
>>
>> Craig White
>>
>> System Administrator
>>
>> O623-201-8179   M602-377-9752
>>
>>  
>>
>> cid:image001.png@01CF86FE.42D51630
>>
>>  
>>
>> SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032
>>
>>  
>>
>> *From:*freeipa-users-boun...@redhat.com
>> [mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Janelle
>> *Sent:* Monday, November 17, 2014 7:43 AM
>> *To:* freeipa-users@redhat.com
>> *Subject:* [Freeipa-users] strange replica creation problem
>>
>>  
>>
>> Happy Monday everyone,
>>
>> I have a strange issue I am seeing with replica creations, but it does
>> not seem to be consistent.  Sometimes, when trying to install the
>> replica I get errors trying to connect to the master via SSH:
>>
>> /[root@ipa3 ~]# ipa-replica-install
>> /var/lib/ipa/replica-info-ipa3.xyzzy.com.gpg
>> Directory Manager (existing master) password:
>>
>> Run connection check to master
>> Check connection from replica to remote master 'ipa2.xyzzy.com':
>>Directory Service: Unsecure port (389): OK
>>Directory Service: Secure port (636): OK
>>Kerberos KDC: TCP (88): OK
>>Kerberos Kpasswd: TCP (464): OK
>>HTTP Server: Unsecure port (80): OK
>>HTTP Server: Secure port (443): OK
>>
>> The following list of ports use UDP protocol and would need to be
>> checked manually:
>>Kerberos KDC: UDP (88): SKIPPED
>>Kerberos Kpasswd: UDP (464): SKIPPED
>>
>> Connection from replica to master is OK.
>> Start listening on required ports for remote master check
>> Get credentials to log in to remote master
>> ad...@xyzzy.com  password:
>>
>> Check SSH connection to remote master
>> ad...@ipa2.xyzzy.com 's password:
>> ad...@ipa2.xyzzy.com 's password:
>> Could not SSH into remote host. Error output:
>> OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013
>> debug1: Reading configuration data /etc/ssh/ssh_config
>> debug1: /etc/ssh/ssh_config line 51: Applying options for */
>>
>>
>> ssh via root and all the hosts - using keys - works just fine. I don't
>> understand why this is happening on some hosts and not others.
>>
>>
>> Any ideas?
>> ~J
>>
> 
> 
> 

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

Re: [Freeipa-users] strange replica creation problem

[Janelle]

I did find that as the work-around - just trying to understand why it 
comes up sometimes...
Did you find any issues with the workings of a replica if you had to 
resort to this method?


Thanks.

~J

On 11/17/14 10:57 AM, Craig White wrote:


Janelle, this may not be that useful but I found it worthwhile to 
resort to…


–skip-conncheck

When setting up the replica – pretty much for the same reason.

Craig White

System Administrator

O623-201-8179 M602-377-9752

cid:image001.png@01CF86FE.42D51630

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

*From:*freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Janelle

*Sent:* Monday, November 17, 2014 7:43 AM
*To:* freeipa-users@redhat.com
*Subject:* [Freeipa-users] strange replica creation problem

Happy Monday everyone,

I have a strange issue I am seeing with replica creations, but it does 
not seem to be consistent.  Sometimes, when trying to install the 
replica I get errors trying to connect to the master via SSH:


/[root@ipa3 ~]# ipa-replica-install 
/var/lib/ipa/replica-info-ipa3.xyzzy.com.gpg

Directory Manager (existing master) password:

Run connection check to master
Check connection from replica to remote master 'ipa2.xyzzy.com':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
ad...@xyzzy.com  password:

Check SSH connection to remote master
ad...@ipa2.xyzzy.com 's password:
ad...@ipa2.xyzzy.com 's password:
Could not SSH into remote host. Error output:
OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 51: Applying options for */


ssh via root and all the hosts - using keys - works just fine. I don't 
understand why this is happening on some hosts and not others.



Any ideas?
~J



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

Re: [Freeipa-users] Group membership not populated

[Jakub Hrozek]

On Fri, Nov 14, 2014 at 04:30:17PM +, Darren Poulson wrote:
> Ok,
> 
> I've shoved them on pastebin. They were a bit big to put in a mailing list 
> really.
> 
> ldap_child.log: http://pastebin.com/qGCZF4vK
> sssd_nss.log: http://pastebin.com/gTBA8NEj
> sssd_bur.us.genops.log: http://pastebin.com/ithUqb1z

Seems like this is another instance of sssd_nss.log ?

> 
> I did see this in the sssd_nss.log:
> 
> (Fri Nov 14 16:09:34 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply 
> from Data Provider - DP error code: 3 errno: 17 error message: Init group 
> lookup failed
> (Fri Nov 14 16:09:34 2014) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): 
> Unable to get information from Data Provider
> Error: 3, 17, Init group lookup failed

Right, this is the problem. I'm not sure what's wrong, sssd domain log
would tell us more..

> Will try to return what we have in cache
> (Fri Nov 14 16:09:34 2014) [sssd[nss]] [sss_dp_req_destructor] (0x0400): 
> Deleting request: [0x418850:3:dpoul...@bur.us.genops]
> 
> Which pointed to this:
> 
> https://fedorahosted.org/sssd/ticket/2385
> 
> Which had similar symptoms but is related to AD.

Yes, I'm afraid we're looking at a different issue, #2385 was indeed
AD-specific.

-- 
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] strange replica creation problem

[Craig White]

Janelle, this may not be that useful but I found it worthwhile to resort to…

–skip-conncheck

When setting up the replica – pretty much for the same reason.

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

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

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

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
Sent: Monday, November 17, 2014 7:43 AM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] strange replica creation problem

Happy Monday everyone,

I have a strange issue I am seeing with replica creations, but it does not seem 
to be consistent.  Sometimes, when trying to install the replica I get errors 
trying to connect to the master via SSH:

[root@ipa3 ~]# ipa-replica-install /var/lib/ipa/replica-info-ipa3.xyzzy.com.gpg
Directory Manager (existing master) password:

Run connection check to master
Check connection from replica to remote master 'ipa2.xyzzy.com':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
ad...@xyzzy.com password:

Check SSH connection to remote master
ad...@ipa2.xyzzy.com's password:
ad...@ipa2.xyzzy.com's password:
Could not SSH into remote host. Error output:
OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 51: Applying options for *


ssh via root and all the hosts - using keys - works just fine. I don't 
understand why this is happening on some hosts and not others.


Any ideas?
~J
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

[Freeipa-users] Questions about commande ipa user-add used to import NIS accounts

[Edouard Guigné]

Hello freeipa users

I followed the instructions of this page :
http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords

in order to integrate NIS accounts over IPA with preserving passwords.

However, I do not succeed to import user as indicate on documentation :

# ipa user-add /user1/--setattr=userpassword={CRYPT}//
return :
*"ipa: ERROR: Constraint violation : invalid password syntax - passwords 
with storage scheme are not allowed"*


Someone could help ?

Ed
-- 
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 Kerberos and Single-DES for OpenAFS

[Simo Sorce]

On Mon, 17 Nov 2014 13:59:44 +0100
Andreas Ladanyi  wrote:

> >
>  Hi,
> 
>  I set up the 389 LDAP server to support des-cbc-crc enctype.
> 
>  I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4
>  (single-DES). I created the principal with:
> 
>  kadmin.local -x ipa-setup-override-restrictions
> >>> Please don't do this, use the ipa service-add and ipa-getkeytab
> >>> commands instead.
> >> I cant use ipa service-add, because for OpenAFS i need a service
> >> principal called:
> >>
> >> afs/cellname@REALM , the cellname could be any name. In my case the
> >> cellname is the same like the domainname.
> > [root@cc21 ~]# ipa host-add --force afs-cellname.ipacloud.test
> > ---
> > Added host "afs-cellname.ipacloud.test"
> > ---
> >  Host name: afs-cellname.ipacloud.test
> >  Principal name: host/afs-cellname.ipacloud.t...@ipacloud.test
> >  Password: False
> >  Keytab: False
> >  Managed by: afs-cellname.ipacloud.test
> > [root@cc21 ~]# ipa service-add --force afs/afs-cellname
> > --
> > Added service "afs/afs-celln...@ipacloud.test"
> > --
> >  Principal: afs/afs-celln...@ipacloud.test
> >  Managed by: afs-cellname.ipacloud.test
> > [root@cc21 ~]# ipa service-show afs/afs-cellname
> >  Principal: afs/afs-celln...@ipacloud.test
> >  Keytab: False
> >  Managed by: afs-cellname.ipacloud.test
> > [root@cc21 ~]# ipa-getkeytab -s `hostname` -p afs/afs-cellname   -k
> > /tmp/afs.keytab Keytab successfully retrieved and stored in:
> > /tmp/afs.keytab
> >
> > As you can see there is no problem at all -- all you need is to
> > have a host entry with the same name as afs-cellname. Note that the
> > host afs-cellname doesn't even need to exist in DNS.
> >
> > However, your primary problem would be in a different area. You'll
> > need to enable weak crypto at KDC server, Kerberos clients, and
> > LDAP servers.
> >
> > krb5.conf (on both IPA masters and clients):
> > [libdefaults]
> >  allow_weak_crypto = true
> >
> > /var/kerberos/krb5kdc/kdc.conf (on IPA masters):
> > [realms]
> > IPACLOUD.TEST = {
> >   supported_enctypes = aes256-cts-hmac-sha1-96:normal
> > aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal
> > arcfour-hmac-md5:normal des-cbc-crc:v4
> > }
> >
> > Finally, you need to modify
> > cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test
> > and add des-cbc-crc:v4 to supported Kerberos encryption types with
> > krbSupportedEncSaltTypes
> > attribute. You have to use ldapmodify as cn=Directory Manager for
> > that as we don't allow admins to modify these entries directly.
> >
> > A simplified approach would be to use ipa-ldap-updater with your own
> > update file (which should have a name like -.update
> > where  is something between 01 and 90):
> >
> > [root@cc21 ~]# cat 20-weak-enctypes.update dn:
> > cn=$REALM,cn=kerberos,$SUFFIX
> > add: krbSupportedEncSaltTypes: des-cbc-crc:v4
> >
> > [root@cc21 ~]# ipa-ldap-updater ./20-weak-enctypes.update Directory
> > Manager password:
> > Parsing update file './20-weak-enctypes.update'
> > Updating existing entry:
> > cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test
> > Done
> > The ipa-ldap-updater command was successful
> >
> > Only after that you'll get ipa-getkeytab to generate weaker
> > encryption type-based keys. 
> 
> Thats interesting. Now i can receive afs/cellname@REALM service
> tickets with des-cbc-crc and aes256 key on the client but only when i
> execute:
> 
> kvno -e des-cbc-crc afs/cellname
> 
> If i execute aklog to obtain an afs token from tgt i get a
> afs/cellname@REALM service ticket without des-cbc-crc key.

This is probably because you got all default enctypes in the key, so
the KDC is sending you a ticket with the strongest keytype for which it
has a shared key with the service.

> > However, we have a problem in FreeIPA 4.x that an
> > attempt to force only a specific encryption type in ipa-getkeytab is
> > ignored and instead only enctypes from krbDefaultEncSaltTypes
> > attribute are generated. This bug is tracked with
> > https://fedorahosted.org/freeipa/ticket/4718

This is the bug that is causing your last issue ^^

One way around it is to use an older ipa-getkeytab binary (like the one
on RHEL 6) that uses the old setkeytab control.

We are working on a fix upstream and will land it asap.

Simo.


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

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

[Freeipa-users] strange replica creation problem

[Janelle]

Happy Monday everyone,

I have a strange issue I am seeing with replica creations, but it does 
not seem to be consistent.  Sometimes, when trying to install the 
replica I get errors trying to connect to the master via SSH:


/[root@ipa3 ~]# ipa-replica-install 
/var/lib/ipa/replica-info-ipa3.xyzzy.com.gpg //

//Directory Manager (existing master) password: //
//
//Run connection check to master//
//Check connection from replica to remote master 'ipa2.xyzzy.com'://
//   Directory Service: Unsecure port (389): OK//
//   Directory Service: Secure port (636): OK//
//   Kerberos KDC: TCP (88): OK//
//   Kerberos Kpasswd: TCP (464): OK//
//   HTTP Server: Unsecure port (80): OK//
//   HTTP Server: Secure port (443): OK//
//
//The following list of ports use UDP protocol and would need to be//
//checked manually://
//   Kerberos KDC: UDP (88): SKIPPED//
//   Kerberos Kpasswd: UDP (464): SKIPPED//
//
//Connection from replica to master is OK.//
//Start listening on required ports for remote master check//
//Get credentials to log in to remote master//
//ad...@xyzzy.com password: //
//
//Check SSH connection to remote master//
//ad...@ipa2.xyzzy.com's password: //
//ad...@ipa2.xyzzy.com's password: //
//Could not SSH into remote host. Error output://
//OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013//
//debug1: Reading configuration data /etc/ssh/ssh_config//
//debug1: /etc/ssh/ssh_config line 51: Applying options for */


ssh via root and all the hosts - using keys - works just fine. I don't 
understand why this is happening on some hosts and not others.



Any ideas?
~J

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

Re: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS

[Dmitri Pal]

On 11/17/2014 07:59 AM, Andreas Ladanyi wrote:

Hi,

I set up the 389 LDAP server to support des-cbc-crc enctype.

I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4
(single-DES). I created the principal with:

kadmin.local -x ipa-setup-override-restrictions

Please don't do this, use the ipa service-add and ipa-getkeytab
commands instead.

I cant use ipa service-add, because for OpenAFS i need a service
principal called:

afs/cellname@REALM , the cellname could be any name. In my case the
cellname is the same like the domainname.

[root@cc21 ~]# ipa host-add --force afs-cellname.ipacloud.test
---
Added host "afs-cellname.ipacloud.test"
---
  Host name: afs-cellname.ipacloud.test
  Principal name: host/afs-cellname.ipacloud.t...@ipacloud.test
  Password: False
  Keytab: False
  Managed by: afs-cellname.ipacloud.test
[root@cc21 ~]# ipa service-add --force afs/afs-cellname
--
Added service "afs/afs-celln...@ipacloud.test"
--
  Principal: afs/afs-celln...@ipacloud.test
  Managed by: afs-cellname.ipacloud.test
[root@cc21 ~]# ipa service-show afs/afs-cellname
  Principal: afs/afs-celln...@ipacloud.test
  Keytab: False
  Managed by: afs-cellname.ipacloud.test
[root@cc21 ~]# ipa-getkeytab -s `hostname` -p afs/afs-cellname   -k
/tmp/afs.keytab Keytab successfully retrieved and stored in:
/tmp/afs.keytab

As you can see there is no problem at all -- all you need is to have a
host entry with the same name as afs-cellname. Note that the host
afs-cellname doesn't even need to exist in DNS.

However, your primary problem would be in a different area. You'll need
to enable weak crypto at KDC server, Kerberos clients, and LDAP servers.

krb5.conf (on both IPA masters and clients):
[libdefaults]
  allow_weak_crypto = true

/var/kerberos/krb5kdc/kdc.conf (on IPA masters):
[realms]
IPACLOUD.TEST = {
   supported_enctypes = aes256-cts-hmac-sha1-96:normal
aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal
arcfour-hmac-md5:normal des-cbc-crc:v4
}

Finally, you need to modify
cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test
and add des-cbc-crc:v4 to supported Kerberos encryption types with
krbSupportedEncSaltTypes
attribute. You have to use ldapmodify as cn=Directory Manager for that
as we don't allow admins to modify these entries directly.

A simplified approach would be to use ipa-ldap-updater with your own
update file (which should have a name like -.update where
 is something between 01 and 90):

[root@cc21 ~]# cat 20-weak-enctypes.update dn:
cn=$REALM,cn=kerberos,$SUFFIX
add: krbSupportedEncSaltTypes: des-cbc-crc:v4

[root@cc21 ~]# ipa-ldap-updater ./20-weak-enctypes.update Directory
Manager password:
Parsing update file './20-weak-enctypes.update'
Updating existing entry:
cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test
Done
The ipa-ldap-updater command was successful

Only after that you'll get ipa-getkeytab to generate weaker encryption
type-based keys.

Thats interesting. Now i can receive afs/cellname@REALM service tickets
with des-cbc-crc and aes256 key on the client but only when i execute:

kvno -e des-cbc-crc afs/cellname

If i execute aklog to obtain an afs token from tgt i get a
afs/cellname@REALM service ticket without des-cbc-crc key.


Are they using same krb5.conf?




However, we have a problem in FreeIPA 4.x that an
attempt to force only a specific encryption type in ipa-getkeytab is
ignored and instead only enctypes from krbDefaultEncSaltTypes attribute
are generated. This bug is tracked with
https://fedorahosted.org/freeipa/ticket/4718




--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

Re: [Freeipa-users] Group membership not populated

[Darren Poulson]

That seems to have done the trick.

Many thanks to all who helped. Now to deploy this thing! :D

From: Lukas Slebodnik [lsleb...@redhat.com]
Sent: 15 November 2014 15:17
To: Darren Poulson
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Group membership not populated

On (15/11/14 15:01), Darren Poulson wrote:
>Sorry, it seems I failed at cutting and pasting.
>
>sssd_bur.us.genops.log http://pastebin.com/7c5bH1Wq
>
Thank you very much for log file.
It is know bug:
https://fedorahosted.org/sssd/ticket/2471
https://bugzilla.redhat.com/show_bug.cgi?id=1154042
You can use workaround to fix this regression.
Put following line into domain section in /etc/sssd/sssd.conf
ldap_group_object_class = ipaUserGroup

LS




-- 
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 Kerberos and Single-DES for OpenAFS

[Andreas Ladanyi]

>
 Hi,

 I set up the 389 LDAP server to support des-cbc-crc enctype.

 I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4
 (single-DES). I created the principal with:

 kadmin.local -x ipa-setup-override-restrictions
>>> Please don't do this, use the ipa service-add and ipa-getkeytab
>>> commands instead.
>> I cant use ipa service-add, because for OpenAFS i need a service
>> principal called:
>>
>> afs/cellname@REALM , the cellname could be any name. In my case the
>> cellname is the same like the domainname.
> [root@cc21 ~]# ipa host-add --force afs-cellname.ipacloud.test
> ---
> Added host "afs-cellname.ipacloud.test"
> ---
>  Host name: afs-cellname.ipacloud.test
>  Principal name: host/afs-cellname.ipacloud.t...@ipacloud.test
>  Password: False
>  Keytab: False
>  Managed by: afs-cellname.ipacloud.test
> [root@cc21 ~]# ipa service-add --force afs/afs-cellname
> --
> Added service "afs/afs-celln...@ipacloud.test"
> --
>  Principal: afs/afs-celln...@ipacloud.test
>  Managed by: afs-cellname.ipacloud.test
> [root@cc21 ~]# ipa service-show afs/afs-cellname
>  Principal: afs/afs-celln...@ipacloud.test
>  Keytab: False
>  Managed by: afs-cellname.ipacloud.test
> [root@cc21 ~]# ipa-getkeytab -s `hostname` -p afs/afs-cellname   -k
> /tmp/afs.keytab Keytab successfully retrieved and stored in:
> /tmp/afs.keytab
>
> As you can see there is no problem at all -- all you need is to have a
> host entry with the same name as afs-cellname. Note that the host
> afs-cellname doesn't even need to exist in DNS.
>
> However, your primary problem would be in a different area. You'll need
> to enable weak crypto at KDC server, Kerberos clients, and LDAP servers.
>
> krb5.conf (on both IPA masters and clients):
> [libdefaults]
>  allow_weak_crypto = true
>
> /var/kerberos/krb5kdc/kdc.conf (on IPA masters):
> [realms]
> IPACLOUD.TEST = {
>   supported_enctypes = aes256-cts-hmac-sha1-96:normal
> aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal
> arcfour-hmac-md5:normal des-cbc-crc:v4
> }
>
> Finally, you need to modify
> cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test
> and add des-cbc-crc:v4 to supported Kerberos encryption types with
> krbSupportedEncSaltTypes
> attribute. You have to use ldapmodify as cn=Directory Manager for that
> as we don't allow admins to modify these entries directly.
>
> A simplified approach would be to use ipa-ldap-updater with your own
> update file (which should have a name like -.update where
>  is something between 01 and 90):
>
> [root@cc21 ~]# cat 20-weak-enctypes.update dn:
> cn=$REALM,cn=kerberos,$SUFFIX
> add: krbSupportedEncSaltTypes: des-cbc-crc:v4
>
> [root@cc21 ~]# ipa-ldap-updater ./20-weak-enctypes.update Directory
> Manager password:
> Parsing update file './20-weak-enctypes.update'
> Updating existing entry:
> cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test
> Done
> The ipa-ldap-updater command was successful
>
> Only after that you'll get ipa-getkeytab to generate weaker encryption
> type-based keys. 

Thats interesting. Now i can receive afs/cellname@REALM service tickets
with des-cbc-crc and aes256 key on the client but only when i execute:

kvno -e des-cbc-crc afs/cellname

If i execute aklog to obtain an afs token from tgt i get a
afs/cellname@REALM service ticket without des-cbc-crc key.

> However, we have a problem in FreeIPA 4.x that an
> attempt to force only a specific encryption type in ipa-getkeytab is
> ignored and instead only enctypes from krbDefaultEncSaltTypes attribute
> are generated. This bug is tracked with
> https://fedorahosted.org/freeipa/ticket/4718
>

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