Re: [Freeipa-users] Problem in ipa-server-install - uninstall - install
On Tue, Feb 14, 2012 at 8:25 PM, Rob Crittenden rcrit...@redhat.com wrote: Marco Pizzoli wrote: On Tue, Feb 14, 2012 at 3:24 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Marco Pizzoli wrote: Hi guys, I'm running freeipa-server-2.1.4-5.fc16.__**x86_64. Following the documentation I can see that to uninstall and reinstall a freeipa system it is sufficient to: ipa-server-install parameters ipa-server-install --uninstall ipa-server-install parameters Well, when re-installing the system, I get this error on the console: [cut] done configuring named. Configuration of client side components failed! ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master --unattended --domain unix.mydomain.it http://unix.mydomain.it http://unix.mydomain.it --server freeipa01.unix.mydomain.it http://freeipa01.unix.**mydomain.ithttp://freeipa01.unix.mydomain.it http://freeipa01.unix.__mydom**ain.it http://mydomain.it http://freeipa01.unix.**mydomain.ithttp://freeipa01.unix.mydomain.it --realm UNIX.MYDOMAIN.IT http://UNIX.MYDOMAIN.IT http://UNIX.MYDOMAIN.IT --hostname freeipa01.unix.mydomain.it http://freeipa01.unix.**mydomain.ithttp://freeipa01.unix.mydomain.it http://freeipa01.unix.__mydom**ain.it http://mydomain.it http://freeipa01.unix.**mydomain.ithttp://freeipa01.unix.mydomain.it' returned non-zero exit status 1 I had a look to /var/log/ipaclient-install.log and I saw these lines [cut] 2012-02-14 09:53:39,435 DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://freeipa01.unix.__mydoma**in.it/ipa/config/ca.crthttp://mydomain.it/ipa/config/ca.crt http://freeipa01.unix.**mydomain.it/ipa/config/ca.crthttp://freeipa01.unix.mydomain.it/ipa/config/ca.crt 2012-02-14 09:53:39,435 DEBUG stdout= 2012-02-14 09:53:39,435 DEBUG stderr=--2012-02-14 09:53:39-- http://freeipa01.unix.__mydoma**in.it/ipa/config/ca.crthttp://mydomain.it/ipa/config/ca.crt http://freeipa01.unix.**mydomain.it/ipa/config/ca.crthttp://freeipa01.unix.mydomain.it/ipa/config/ca.crt Resolving freeipa01.unix.mydomain.it... 192.168.146.131 Connecting to freeipa01.unix.mydomain.it http://freeipa01.unix.**mydomain.ithttp://freeipa01.unix.mydomain.it http://freeipa01.unix.__mydom**ain.it http://mydomain.it http://freeipa01.unix.**mydomain.ithttp://freeipa01.unix.mydomain.it |192.168.146.131|**:__80... connected. HTTP request sent, awaiting response... 200 OK Length: 1325 (1.3K) [application/x-x509-ca-cert] Saving to: E2809C/etc/ipa/ca.crt__**E2809D 0K . 100% 270M=0s 2012-02-14 09:53:39 (270 MB/s) - E2809C/etc/ipa/ca.crt__**E2809D saved [1325/1325] 2012-02-14 09:53:39,436 DEBUG Backing up system configuration file '/etc/sssd/sssd.conf' 2012-02-14 09:53:39,463 DEBUG Saving Index File to '/var/lib/ipa-client/__**sysrestore/sysrestore.index' 2012-02-14 09:53:39,540 DEBUG Domain unix.csebo.it http://unix.csebo.it http://unix.csebo.it is already configured in existing SSSD config, creating a new one. 2012-02-14 09:53:39,642 DEBUG args=/usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i /etc/ipa/ca.crt 2012-02-14 09:53:39,643 DEBUG stdout= 2012-02-14 09:53:39,643 DEBUG stderr=certutil: could not obtain certificate from file: You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. So I tried a new ipa-server-install --uninstall and checked the file /etc/ipa/ca.crt. And it remained there. What is the problem? The problem isn't the existence of the file, it is the existence of the cert in /etc/pki/nssdb. Try running: certutil -D -n 'IPA CA' -d /etc/pki/nsdb [root@freeipa01 ~]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb/ certutil: could not find certificate named IPA CA: security library: bad database. Well that's strange. Can you run: certutil -L -d /etc/pki/nssdb ? More strange... I re-did a freeipa-install and it worked... Thanks anyway ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Solaris kerberos - fail
Hi, I see that the documentation for configuring kerberos on Solaris has changed since the last time I looked. http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 kclient fails if I pre-create the account in IPA, and attempt to kclient configure the client. If I don't, it successfully retreives a keytab for the host, but I'm unable to add the host as a host in IPA as the kerberos principal is already used. I suppose there is a LDAP ACL preventing me from doing this? Can I work around this somehow, having the host account in IPA and using kclient to configure Solaris hosts at the same time? I have edited /var/kerberos/krb5kdc/kadm5.acl : -- */ad...@ix.test.com * -- -- # kclient Starting client setup --- Do you want to use DNS for kerberos lookups ? [y/n]: n No action performed. Enter the Kerberos realm: IX.TEST.COM Specify the KDC hostname for the above realm: ipa01.ix.test.com ipa01.ix.test.com Note, this system and the KDC's time must be within 5 minutes of each other for Kerberos to function. Both systems should run some form of time synchronization system like Network Time Protocol (NTP). Setting up /etc/krb5/krb5.conf. Enter the krb5 administrative principal to be used: soladmin Obtaining TGT for soladmin/admin ... Password for soladmin/ad...@ix.test.com: Do you have multiple DNS domains spanning the Kerberos realm IX.NIXTRA.COM ? [y/n]: n No action performed. Do you plan on doing Kerberized nfs ? [y/n]: n No action performed. host/server2.ix.nixtra.com entry already exists in KDC database. Authenticating as principal soladmin/ad...@ix.nixtra.com with existing credentials. kadmin: Insufficient access to perform requested operation while changing host/server2.ix.nixtra.com's key Administration credentials NOT DESTROYED. kadmin: ktadd of host/server2.ix.test.com failed, exiting. --- Setup FAILED. -- From /var/log/kadmind.log: -- Feb 15 19:56:49 ipa01.ix.test.com kadmind[22727](Notice): Request: kadm5_init, soladmin/ad...@ix.test.com, success, client=soladmin/ad...@ix.test.com, service=kadmin/ipa01.ix.test@ix.test.com, addr=192.168.1.238, vers=2, flavor=6 Feb 15 19:56:49 ipa01.ix.test.com kadmind[22727](Notice): Request: kadm5_randkey_principal, host/server2.ix.test@ix.test.com, User modification failed: Insufficient access, client=soladmin/ad...@ix.test.com, service=kadmin/ipa01.ix.test@ix.test.com, addr=192.168.1.238 -- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Solaris kerberos - fail
Sigbjorn Lie wrote: On 02/15/2012 09:06 PM, Rob Crittenden wrote: You might try adding soladmin to the Host Administrators role and see if it works then. If it does you'll probably want to create a new role with more limited permissions. I would imagine that a host added this way would not appear as an IPA-managed host (though adding the host first and using this to just add the key should be ok). rob The version is: freeipa-server-2.1.3-2.fc15.x86_64 The kclient script only accepts a parameter -a adminuser, which it translates into adminuser/admin. How can I add this to a IPA role? If I attempt to work around that by using kadmin directly instead of the wrapper kclient script on the Solaris host, and specifying the IPA default admin account, the same message occur: # kadmin -p admin -q ktadd -k /etc/krb5/krb5.keytab host/server2.ix.test@ix.test.com Authenticating as principal admin with password. Password for ad...@ix.test.com: kadmin: Insufficient access to perform requested operation while changing host/server2.ix.test@ix.test.com's key /var/kerberos/krb5kdc/kadm5.acl: ad...@ix.test.com * /var/log/kadmind.log: Feb 15 21:18:41 ipa01.ix.test.com kadmind[22727](Notice): Request: kadm5_init, ad...@ix.test.com, success, client=ad...@ix.test.com, service=kadmin/ipa01.ix.test@ix.test.com, addr=192.168.1.238, vers=2, flavor=6 Feb 15 21:18:41 ipa01.ix.test.com kadmind[22727](Notice): Request: kadm5_randkey_principal, host/server2.ix.test@ix.test.com, User modification failed: Insufficient access, client=ad...@ix.test.com, service=kadmin/ipa01.ix.test@ix.test.com, addr=192.168.1.238 To be honest, the whole section about kclient, kadmin, etc is new to me as well. I don't know when that was added. We'll investigate that, sorry about the confusion. These problems are likely related to the fact that kadmin assumes a different DIT than IPA. We don't recommend kadmin be used. We recommend using ipa-getkeytab on a Linux box and retrieving the keytab that way. Yes, this is less than convenient. On Solaris 10 you may have a fighting chance of building ipa-getkeytab natively. I seem to recall a bunch of optional packages to add various LDAP and compiler parts you'd need but it is less than ideal. I had absolutely no luck on Solaris 9 without having to compile everything myself. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Solaris kerberos - fail
On Wed, 2012-02-15 at 22:55 +0100, Sigbjorn Lie wrote: On 02/15/2012 09:32 PM, Simo Sorce wrote: On Wed, 2012-02-15 at 20:49 +0100, Sigbjorn Lie wrote: Hi, I see that the documentation for configuring kerberos on Solaris has changed since the last time I looked. http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 kclient fails if I pre-create the account in IPA, and attempt to kclient configure the client. If I don't, it successfully retreives a keytab for the host, but I'm unable to add the host as a host in IPA as the kerberos principal is already used. I suppose there is a LDAP ACL preventing me from doing this? Can I work around this somehow, having the host account in IPA and using kclient to configure Solaris hosts at the same time? Sigbjorn, running kadmind in FreeIPA 2.2 is completely unsupported and there are ACLs that explicitly prevent it from changing data in LDAP. I will investigate about those instructions and correct them as necessary, they appear incorrect. Yes, I was a bit surprised when I noticed this in the documentation given other postings on the list where use of kadmin and kadmin.local is advised to be not supported. Does something change in 2.2 and upwards to support the use of kadmin ? Yes and no. In 2.2 we have our own kdb backend and we decided to retire ipa_kpasswd and use kadmind instead. But I still prevent kadmin from doing a lot of operations, because kadmind has no clue how to properly create an ipa computer object or an ipa user. In time we may teach kadmin how to properly handle some of the principals, but for now I am simply preventing it from messing up the tree by crating bare principals in the wrong place, with the wrong (or missing) data attached to it. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replicas in a state of confusion
On 02/10/2012 01:00 PM, Ian Levesque wrote: On Feb 10, 2012, at 1:36 PM, Rich Megginson wrote: This may be related to https://fedorahosted.org/389/ticket/273 and https://fedorahosted.org/389/ticket/274 which have been fixed in 1.2.10 In this case Ian please open a bugzilla, it looks like we need to address this in RHEL6. I'll confess that I don't fully understand what tombstone is... Regardless, I'm not sure that either of those tickets apply to the issue at hand. As I understand it, Ticket 273 outlines an issue with searching for tombstone entries after successfully setting up a replica (which as far as I'm hearing, we haven't done). And ticket 274 concerns indexing the tombstone entries. I am able to search for tombstone entries (http://pastebin.com/raw.php?i=a4ytYZvt) and don't see the errors specified in ticket 274. in 1.2.9.9 the ruv tombstone entry was indexed correctly, so that's why you see it. For ticket 274, you would only see those errors if you actually attempt to reindex the entryrdn index. That said, perhaps there's some bug with tombstone re: the automountmap entries in my LDAP instance. Do you think that would be sufficient to cause the replication issues I'm seeing? It could be. Taken together, both of those tickets resolve problems with tombstone indexes. At any rate, I would like to know if you can reproduce your issues with 1.2.10.rc1 To confirm, the first step would be to examine your entryrdn index to see what the problematic entries look like e.g. dbscan -f /var/lib/dirsrv/slapd-DOMAIN/db/userRoot/entryrdn.db4 | grep -C 2 automountmapname=auto.direct Here's the output from the primary: 139:cn=global_policy ID: 139; RDN: cn=global_policy; NRDN: cn=global_policy 13:nsuniqueid=3c37a107-eadf11e0-b9798103-f403dc04,automountmapname=auto.direct ID: 13; RDN: nsuniqueid=3c37a107-eadf11e0-b9798103-f403dc04,automountmapname=auto.direct; NRDN: nsuniqueid=3c37a107-eadf11e0-b9798103-f403dc04,automountmapname=auto.direct 141:krbprincipalname=ldap/sbgrid-directory.in.hw...@sbgrid.org ID: 141; RDN: krbprincipalname=ldap/sbgrid-directory.in.hw...@sbgrid.org; NRDN: krbprincipalname=ldap/sbgrid-directory.in.hw...@sbgrid.org -- 450:nsuniqueid=61a1ff02-370b11e1-80c28103-f403dc04,automountmapname=auto.master ID: 450; RDN: nsuniqueid=61a1ff02-370b11e1-80c28103-f403dc04,automountmapname=auto.master; NRDN: nsuniqueid=61a1ff02-370b11e1-80c28103-f403dc04,automountmapname=auto.master 451:nsuniqueid=61a1ff03-370b11e1-80c28103-f403dc04,automountmapname=auto.direct ID: 451; RDN: nsuniqueid=61a1ff03-370b11e1-80c28103-f403dc04,automountmapname=auto.direct; NRDN: nsuniqueid=61a1ff03-370b11e1-80c28103-f403dc04,automountmapname=auto.direct 452:nsuniqueid=61a1ff04-370b11e1-80c28103-f403dc04,description=/- auto.direct ID: 452; RDN: nsuniqueid=61a1ff04-370b11e1-80c28103-f403dc04,description=/- auto.direct; NRDN: nsuniqueid=61a1ff04-370b11e1-80c28103-f403dc04,description=/- auto.direct -- 466:automountmapname=auto.master ID: 466; RDN: automountmapname=auto.master; NRDN: automountmapname=auto.master 467:automountmapname=auto.direct ID: 467; RDN: automountmapname=auto.direct; NRDN: automountmapname=auto.direct 468:description=/- auto.direct ID: 468; RDN: description=/- auto.direct; NRDN: description=/- auto.direct -- ID: 12; RDN: nsuniqueid=3c37a106-eadf11e0-b9798103-f403dc04,automountmapname=auto.master; NRDN: nsuniqueid=3c37a106-eadf11e0-b9798103-f403dc04,automountmapname=auto.master C11:cn=default ID: 13; RDN: nsuniqueid=3c37a107-eadf11e0-b9798103-f403dc04,automountmapname=auto.direct; NRDN: nsuniqueid=3c37a107-eadf11e0-b9798103-f403dc04,automountmapname=auto.direct C11:cn=default ID: 261; RDN: nsuniqueid=ee37db01-ee0511e0-b8f78103-f403dc04,automountMapName=auto_master; NRDN: nsuniqueid=ee37db01-ee0511e0-b8f78103-f403dc04,automountmapname=auto_master -- ID: 450; RDN: nsuniqueid=61a1ff02-370b11e1-80c28103-f403dc04,automountmapname=auto.master; NRDN: nsuniqueid=61a1ff02-370b11e1-80c28103-f403dc04,automountmapname=auto.master C449:cn=test ID: 451; RDN: nsuniqueid=61a1ff03-370b11e1-80c28103-f403dc04,automountmapname=auto.direct; NRDN: nsuniqueid=61a1ff03-370b11e1-80c28103-f403dc04,automountmapname=auto.direct C449:cn=test ID: 456; RDN: nsuniqueid=7bdfdb01-371311e1-80c28103-f403dc04,automountmapname=auto_nfs; NRDN: nsuniqueid=7bdfdb01-371311e1-80c28103-f403dc04,automountmapname=auto_nfs -- ID: 464; RDN: nsuniqueid=bdbd5105-371411e1-80c28103-f403dc04,description=home; NRDN: nsuniqueid=bdbd5105-371411e1-80c28103-f403dc04,description=home C465:cn=default ID: 467; RDN: automountmapname=auto.direct; NRDN: automountmapname=auto.direct C465:cn=default ID: 466; RDN: automountmapname=auto.master; NRDN: automountmapname=auto.master -- P139:cn=global_policy ID: 132; RDN: cn=SBGRID.ORG; NRDN: cn=sbgrid.org P13:nsuniqueid=3c37a107-eadf11e0-b9798103-f403dc04,automountmapname=auto.direct ID: 11; RDN: cn=default; NRDN:
Re: [Freeipa-users] kinit: Generic error (see e-text) while getting initial credentials (SOLVED)
On Tue, Feb 14, 2012 at 04:54:51PM -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Mon, 2012-02-13 at 10:39 +1100, Craig T wrote:
Hi,
Server:
RHEL6.2
Spec:
ipa-admintools-2.1.3-9.el6.x86_64
ipa-client-2.1.3-9.el6.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-python-2.1.3-9.el6.x86_64
ipa-server-2.1.3-9.el6.x86_64
ipa-server-selinux-2.1.3-9.el6.x86_64
libipa_hbac-1.5.1-66.el6_2.3.x86_64
libipa_hbac-python-1.5.1-66.el6_2.3.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
Error:
I had this working on Friday night, came in Monday and then this error
appeared?
kinit -V craig
Using default cache: /tmp/krb5cc_0
Using principal: cr...@example.com
kinit: Generic error (see e-text) while getting initial credentials
Server Side Error: (File: /var/log/krb5kdc.log)
Feb 13 10:36:04 sysvm-ipa krb5kdc[5590](info): AS_REQ (4 etypes {18 17 16
23}) 192.168.0.214: LOOKING_UP_CLIENT: cr...@example.com for
krbtgt/example@example.com, unable to decode stored principal key data
(ASN.1 encoding ended unexpectedly)
Usual Questions:
Should I simply reset the password?
It seem like the only option to quickly recover access to your user.
Is it a bug?
It may be. Did you do anything special with this user ? Did this happen
immediately after a password change ? Or immediately after a FreeIPA or
krb5kdc upgrade ?
Can you give a little more context around this ?
Issue Solved!
I worked out that my LDAP Browser was changing the attribtues of
krbPrincipalKey entry just be simply clicking on the attribute entry!! Not a
good idea.
Have a look at the before and after;
BEFORE:
krbPrincipalKey:: MIIBnKADAgEBoQMCAQGiAwIBAqMDAgEApIIBhDCCAYAwaKAbMBmgAwIBBK
ESBBCf338d3SHeIt21wwMeLtrDoUkwR6ADAgESoUAEPiAAltpeSUgnisk9RLvsAXZISub9cfbfJ
/SnxMWlrhrS0fUKaQYGXPXwwwslXgZ30xWfeAlLI9DztmKeqzUbMFigGzAZoAMCAQShEgQQze9p
5zpXYuYLOyWIljg0jaE5MDegAwIBEaEwBC4QAPa4TpZbsA1tSoUl1LMG+IljQusO8zpTD7UqNWI
drvYJI8Cq6rALd/jzMJKgMGCgGzAZoAMCAQShEgQQh3To4HjujECOGDHyhaoFiqFBMD+gAwIBEK
E4BDYYAO4F0DyDLow0cColhjsykUzH750CBFsaZfIEX1o2iPMCWlLYtRmauoW3OhejrRESemC+s
GUwWKAbMBmgAwIBBKESBBDF9qB45XTzfez5BfecBC/EoTkwN6ADAgEXoTAELhAAc9mgsgQnmXxX
qlwrLcC9U7uGePdu95xCQcW9lvRyW77rTpev6Lk4E7sXYKE=
AFTER:
krbPrincipalKey:: MO+/vQHvv73vv70DAgEB77+9AwIBAe+/vQMCAQLvv70DAgE=
---
Also could you ldapsearch this user entry before you change your
password using 'cn=Directory Manager' as user in order to retrieve the
key attribute and send the ldif to me in private ? I want to see if the
key blob at least looks normal (do not worry about your password, the
key material is itself encrypted).
It might also be handy to see who last updated this entry before you
reset the password (if it isn't too late): modifyTimestamp
lastModifiedBy
Anyone else seen this error?
Haven't seen any report, and haven't ever occurred in my testing.
Simo,
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA deployment questions (Open Directory)
Hi Rob, thanks for your responses! On Feb 15, 2012, at 12:16 AM, Rob Crittenden wrote: 389-ds is our LDAP server so we generally support what it can do. AFAIK it does not do replication with OD. What is it you want to replicate, what direction, etc? It seems like users and groups are going to need to be synchronized, but I don't really know. OD has 'apple-user' and 'apple-group' schemas which have zero mandatory attributes. FreeIPA has ipaObject which has the ipaUniqueid mandatory attribute. This is the first time I'm trying these things with LDAP, but it seems that the if an object is created on FreeIPA, could it be replicated to OD? apple-user and apple-group have no mandatory attributes, and once it is replicated to OD, an admin could run Workgroup Manager and use the migrate from legacy tool on the object to create the OD attributes. So I guess that means I am replicating from FreeIPA to OD, but once changes are made on OD, can I replicate back with the additional attributes that are added? If not, changes that are made on FreeIPA would seem to overwrite the new attributes added in OD. Or is there a common way to do this? Is this a reasonable approach or am I overcomplicating things? I've never used the Apache studio but others have reported success. It is probably just a matter of getting your basedn right (e.g. dc=example,dc=com) and perhaps providing a bind user (cn=Directory Manager). Are you getting specific error messages, that might help troubleshoot things. Ok, for others who may follow, here's what worked for me on connecting with Apache DS: 1. Note that the Directory Manager dn is literally cn=Directory Manager, not cn=Directory Manager, dc=example, dc=com. 2. If SSL is desired, be sure to remember to use port 636 instead of 389. This is probably covered in the docs, but alas. :-) Cheers, Brian p.s. Rob, sorry I responded to you directly before, I didn't notice that this list uses reply-to of the sender and not the list. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA documentation comment
Steven Jones wrote: Hi, Sort of minor but I find the following a bit inconsistent, I am looking at section 9.3.1, item no 3 I think it should say, 3. Generate the nfs service keytab, there are two methods, i) On the NFS server, with this command etc etc ii) On a different machine do a)b)...c)...d) The distinction is really whether the machine has ipa-getkeytab or not. The NFS server could be a Solaris machine in which case you'd have to do all this elsewhere. I think this is trying to say if your NFS server is a Linux machine you can directly update /etc/krb5.keytab with these keys and be done with it. Perhaps a little more language about this distinction would help. for your b) You say Copy over to the NFS host machine where earlier you said NFS server, you repeat this in d) for consistency it should be server it certainly slows my understanding down when I see such things being mixed up Yup, I agree. I also see under 6.5.1 point 6 that there is a ipa-getkeytab command but as per NFS is that run on the server that is providing the service? or on the IPA server, I find it unclear...thinking about it its on the target server offering the service I think you are saying, but by then Ive lost my train of thought ipa-getkeytab can be run anywhere for any service. It is just more convenient to run it on the target machine because then you don't have to move around keytabs (and do the nasty work in 9.3.1.3 d). Thanks for the feedback, I opened a doc bug, https://bugzilla.redhat.com/show_bug.cgi?id=791077 Feel free to add more details if I've missed something. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] kinit: Generic error (see e-text) while getting initial credentials (SOLVED)
On Thu, 2012-02-16 at 12:27 +1100, Craig T wrote:
On Tue, Feb 14, 2012 at 04:54:51PM -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Mon, 2012-02-13 at 10:39 +1100, Craig T wrote:
Hi,
Server:
RHEL6.2
Spec:
ipa-admintools-2.1.3-9.el6.x86_64
ipa-client-2.1.3-9.el6.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-python-2.1.3-9.el6.x86_64
ipa-server-2.1.3-9.el6.x86_64
ipa-server-selinux-2.1.3-9.el6.x86_64
libipa_hbac-1.5.1-66.el6_2.3.x86_64
libipa_hbac-python-1.5.1-66.el6_2.3.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
Error:
I had this working on Friday night, came in Monday and then this error
appeared?
kinit -V craig
Using default cache: /tmp/krb5cc_0
Using principal: cr...@example.com
kinit: Generic error (see e-text) while getting initial credentials
Server Side Error: (File: /var/log/krb5kdc.log)
Feb 13 10:36:04 sysvm-ipa krb5kdc[5590](info): AS_REQ (4 etypes {18 17 16
23}) 192.168.0.214: LOOKING_UP_CLIENT: cr...@example.com for
krbtgt/example@example.com, unable to decode stored principal key
data (ASN.1 encoding ended unexpectedly)
Usual Questions:
Should I simply reset the password?
It seem like the only option to quickly recover access to your user.
Is it a bug?
It may be. Did you do anything special with this user ? Did this happen
immediately after a password change ? Or immediately after a FreeIPA or
krb5kdc upgrade ?
Can you give a little more context around this ?
Issue Solved!
I worked out that my LDAP Browser was changing the attribtues of
krbPrincipalKey entry just be simply clicking on the attribute entry!! Not
a good idea.
Have a look at the before and after;
BEFORE:
krbPrincipalKey:: MIIBnKADAgEBoQMCAQGiAwIBAqMDAgEApIIBhDCCAYAwaKAbMBmgAwIBBK
ESBBCf338d3SHeIt21wwMeLtrDoUkwR6ADAgESoUAEPiAAltpeSUgnisk9RLvsAXZISub9cfbfJ
/SnxMWlrhrS0fUKaQYGXPXwwwslXgZ30xWfeAlLI9DztmKeqzUbMFigGzAZoAMCAQShEgQQze9p
5zpXYuYLOyWIljg0jaE5MDegAwIBEaEwBC4QAPa4TpZbsA1tSoUl1LMG+IljQusO8zpTD7UqNWI
drvYJI8Cq6rALd/jzMJKgMGCgGzAZoAMCAQShEgQQh3To4HjujECOGDHyhaoFiqFBMD+gAwIBEK
E4BDYYAO4F0DyDLow0cColhjsykUzH750CBFsaZfIEX1o2iPMCWlLYtRmauoW3OhejrRESemC+s
GUwWKAbMBmgAwIBBKESBBDF9qB45XTzfez5BfecBC/EoTkwN6ADAgEXoTAELhAAc9mgsgQnmXxX
qlwrLcC9U7uGePdu95xCQcW9lvRyW77rTpev6Lk4E7sXYKE=
AFTER:
krbPrincipalKey:: MO+/vQHvv73vv70DAgEB77+9AwIBAe+/vQMCAQLvv70DAgE=
---
Thanks a lot for getting back to us with the cause.
Glad it wasn't our fault :-)
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] BIND Views?
Hi all, Are configuration and management of BIND views a under consideration for any future releases? I tested that wrapping the dynamic-db element provided by bind-sdb could be wrapped by a view 'test' scope and it works fine, so it seems that it could be hacked together by just creating different views pointing to different parts of the DIT. But presumably, the UI would not be able to edit these different views. I searched the archives and the web for any references to using views on FreeIPA and didn't come up with anything, have others requested this functionality? Thanks, Brian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] BIND Views?
On Thu, 2012-02-16 at 00:34 -0500, Brian Topping wrote: Hi all, Are configuration and management of BIND views a under consideration for any future releases? I tested that wrapping the dynamic-db element provided by bind-sdb could be wrapped by a view 'test' scope and it works fine, so it seems that it could be hacked together by just creating different views pointing to different parts of the DIT. But presumably, the UI would not be able to edit these different views. It probably wouldn't, it may actually get quite confuse if it finds multiple zones with the same name. I searched the archives and the web for any references to using views on FreeIPA and didn't come up with anything, have others requested this functionality? We haven't planned on adding this functionality at this stage. But it is something we may want to look at in the future. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
