Re: [Freeipa-users] Change Password From Web App
On Wed, 2009-08-12 at 13:30 +0200, Mark Hannessen wrote:
> Thank you very much,
> Sounds perfect to me.
>
> I am however still running into a problem.
> I tried changing the password using MD5
>
> $coded = array('userpassword' => "{MD5}" . base64_encode( pack( "H*", md5(
> $newpassword ) ) ) );
>
> And using CLEAR
>
> $coded = array('userpassword' => "{CLEAR}$newpassword");
>
> But both resulted into my user not being able to login in anymore.
> What kind of input does freeipa expect for userpassword?
The preferred method for changing the password is to use the
ldappassword operation.
Alternatively just add the plaintext password w/o any prefix.
Simo.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeipa V2 release date ?
On Mon, 2009-08-24 at 18:06 +0200, Rachid Zarouali wrote: > hy all, > i've put my interest in freeipa project, i've seen on the website the 2.0 > release should be available on april/may 2009, > so i'm wondering if the release date of the 2.0 has been modified on any > roadmap and if so , when it will be release ? Hi Rachid, at the moment we do not have a firm release date yet, but we are working to have something out by winter time. 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] Using FreeIPA as password backend for Samba
On Wed, 2009-09-23 at 10:46 +0200, Tomasz Z. Napierala wrote: > Hi, > > I'm currently deploying IPA in our server infrastructure and I came > across one particular problem. > I have several development servers hooked up to IPA. Devs are locally > developing code on them, accessing it through Samba shares. We have like > 120+ devs currently working, so it's a big hassle to manually create smb > accounts, while there's IPA providing logins and passwords. Is there any > way to sync samba passwords with IPA. If you keep samba passwords in Ldap, IPA can automatically generate LM and NT hashes. All you need is the sambaSamAccount objectclass on the user object. Simo. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] slapi-nis installation help
On Tue, 2009-10-06 at 14:43 -0700, garyv wrote: > So my client needs to understand SSHA encryption? > Did I understand that correct? > > I have some really old clients that will only do DES. > (don't laugh) > > Is there a way to change how which encryption algorithm it uses? No and exposing passwords over the network is a particularly bad idea anyways. Can't you use a pam module on your client to perform kerberos authentication instead of compromising all your network accounts for a stupid client ? 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] slapi-nis installation help
On Mon, 2009-10-12 at 10:04 -0700, garyv wrote: > Finally getting back to you. > > The Bad news: You are of course right, but I have ~40 old build > machines to support and alas am not able to walk > away from them. > > The Good News: FreeIPA and the NIS-plugin works with these (FreeBSD > 3.51) > My initial test client had issues and I moved on to > another test client and it works! I am glad it worked for you in the end, if there is anything missing in our documentation that you want to point out, it would be nice to know. (You could even write a small howto on the freeipa.org wiki should you feel particularly generous :-) 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] FreeIPA "crashes" after many mystery connections
On Thu, 2009-10-22 at 16:22 +0100, Andy Singleton wrote: > Hello, > > > > I am trying to solve a mystery. We have 2 replicated FreeIPA servers. > > Today they both stopped receiving requests because the Directory > Server had begun to refuse connections. > > The relevant message is “Not listening for new connections - too many > fds open” > > > > That’s all well and good: I can increase the file descriptor > allowance. > > However, the reason the fds limit was reached was a massive number of > connections from the servers themselves. > > Can someone provide me with an idea for what this might be? > > > > We received 1024 connections in under 1 second: Here is an example > dirsrv access log entry: > > > > [22/Oct/2009:12:29:53 +0200] conn=679021 fd=464 slot=464 connection > from 127.0.0.1 to 127.0.0.1 > > [22/Oct/2009:12:29:53 +0200] conn=679021 op=0 BIND > dn="uid=kdc,cn=sysaccounts,cn=etc,dc=live,dc=tipp > > 24,dc=net" method=128 version=3 > > [22/Oct/2009:12:29:53 +0200] conn=679021 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="uid=kdc,cn= > > sysaccounts,cn=etc,dc=live,dc=tipp24,dc=net" > > > > > > Some final notes: > > Both servers stopped one after the other. First server A, then 1 > second afterwards, server B. > > > > I’m pretty stuck as to what might have caused this. Can you check the krb5kdc logs ? dn="uid=kdc,cn=sysaccounts,cn=etc,dc=live,dc=tipp24,dc=net" is the account used by the kdc (in v1). So it looks like the KDC went crazy trying to connect to the ldap server. 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] As a non-developer, how can I contribute??
On Thu, 2009-10-22 at 18:13 -0700, Sean Brady wrote: > If there is anything that I can do to assist with this project, > whether it be documentation editing, testing, financial (to a limited > degree), or anything else, please let me know. Hi Sean, there are a lot of things you can do. Testing code (both freeipa and sssd + ipa provider) and reporting bugs for example. Also helping out with keeping freeipa.org up to date would be very useful. If you like writing documentation, that is very welcome too. There many areas that are borderline and yet important for admins where howtos would be really appreciated and so on. You don't need a developer to help, just look at the project and identify a week area where you think you can contribute and let us know what you plan to do. 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] FreeIPA "crashes" after many mystery connections
On Fri, 2009-10-23 at 09:59 +0100, Andy Singleton wrote: > There isn't much in the krb5kdc.logs. > Server A has a few entries about a minute before the incident. Then > nothing until we had to reboot the box. Very strange ... Do yo ustill have the DS error log ? Anything in there ? 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] FreeIPA "crashes" after many mystery connections
On Mon, 2009-10-26 at 08:46 +, Andy Singleton wrote: > As far as I can see, whatever was trying to connect kept trying, and > filling up new slots as they became available until I rebooted. How many clients do you have ? 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] FreeIPA "crashes" after many mystery connections
On Mon, 2009-10-26 at 14:13 +, Andy Singleton wrote: > There are 26 IPA clients, 28 users, and 4 FreeIPA servers (of which only > 2 are used by clients for authentication at present). They are not many so even the default of ~1000 available FDs shouldn't be a problem. I guess I can't help you further unless we can find what caused so many connections. 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: Fwd: [Freeipa-users] Library to change expired password
On Fri, 2009-10-30 at 18:16 -0400, Dan Scott wrote: > OK, that makes sense, thanks. But there's still one thing I don't > really understand. How do the ipa tools obtain a ticket for the RPC > when the password has expired? They don't, password change is done via kpasswd (or direct connection to ldap and ldappasswd operation). 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: Fwd: [Freeipa-users] Library to change expired password
On Sun, 2009-11-01 at 22:26 -0500, Dan Scott wrote: > On Sat, Oct 31, 2009 at 12:50, Simo Sorce wrote: > > On Fri, 2009-10-30 at 18:16 -0400, Dan Scott wrote: > >> OK, that makes sense, thanks. But there's still one thing I don't > >> really understand. How do the ipa tools obtain a ticket for the RPC > >> when the password has expired? > > > > They don't, password change is done via kpasswd (or direct connection to > > ldap and ldappasswd operation). > > So kpasswd can alter the LDAP directory without a ticket? kpasswd can take a ticket for kadmin/chang...@realm > Let me check to see if I've got this straight. There are no IPA > specific tools for changing an expired password? Admin can always reset other users passwords, but they will be expired. > It can be done using > kpasswd (Which I really don't understand) or with a simple ldap bind > where the expired password is used for binding? Further, there is no > python library for changing the expired password? Is the above > correct? Correct. > The only way that I can see at the moment is to 'manually' alter the > LDAP directory. i.e. Hash the password myself and insert it into the > database. Could someone point me in the right direction for the cn and > hashing algorithm I need to use? No prehashed password are refused, we need the clear text password to be able to create the kerberos keys. The best way is to use the ldappasswd extended operation, although probably writing the clear text password to userPassword should also work. 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: Fwd: [Freeipa-users] Library to change expired password
On Tue, 2009-11-03 at 16:31 -0500, Dan Scott wrote: > Sorry again, forgot to CC the mailing list. > > Dan > > On Tue, Nov 3, 2009 at 16:10, Dan Scott wrote: > > Hi, > > > > On Mon, Nov 2, 2009 at 07:33, Simo Sorce wrote: > >> On Sun, 2009-11-01 at 22:26 -0500, Dan Scott wrote: > >>> On Sat, Oct 31, 2009 at 12:50, Simo Sorce wrote: > >>> > On Fri, 2009-10-30 at 18:16 -0400, Dan Scott wrote: > >>> >> OK, that makes sense, thanks. But there's still one thing I don't > >>> >> really understand. How do the ipa tools obtain a ticket for the RPC > >>> >> when the password has expired? > >>> > > >>> > They don't, password change is done via kpasswd (or direct connection to > >>> > ldap and ldappasswd operation). > >>> > >>> So kpasswd can alter the LDAP directory without a ticket? > >> > >> kpasswd can take a ticket for kadmin/chang...@realm > > > > So is that a 'special' ticket, which can be obtained with an expired > > password? Which can then be used to change the user's password? Pretty much. > >>> Let me check to see if I've got this straight. There are no IPA > >>> specific tools for changing an expired password? > >> > >> Admin can always reset other users passwords, but they will be expired. > > > > Well sure, :) but changing a users expired password for another > > expired password doesn't really help. I meant more along the lines > > that there are no IPA specific tools which allow a non-admin user to > > change their own expired password. Yes the tool is called "kpasswd" :) Or if you have properly configured (and it should if you use ipa-client-install) you should also be able to use the normal "passwd" command and perform the password change through the pam password stack. > >>> The only way that I can see at the moment is to 'manually' alter the > >>> LDAP directory. i.e. Hash the password myself and insert it into the > >>> database. Could someone point me in the right direction for the cn and > >>> hashing algorithm I need to use? > >> > >> No prehashed password are refused, we need the clear text password to be > >> able to create the kerberos keys. > >> The best way is to use the ldappasswd extended operation, although > >> probably writing the clear text password to userPassword should also > >> work. > > > > OK, thanks. I've located a Java library which implements the correct > > LDAP extended operations. I can change a non-expired password with no > > problem, but I still can't change an expired password. I am using: > > > > http://www.unboundid.com/products/ldapsdk/ > > > > and I am attempting to bind to the LDAP directory using SimpleBindRequest > > > > http://www.unboundid.com/products/ldapsdk/docs/javadoc/com/unboundid/ldap/sdk/SimpleBindRequest.html > > > > This works fine for changing currently valid passwords, but I receive > > "LDAPException :invalid credentials" when attempting to bind using an > > expired password. Do I need to use a different bind type? There are > > several available: ANONYMOUSBindRequest, CRAMMD5BindRequest, > > DIGESTMD5BindRequest, EXTERNALBindRequest, GSSAPIBindRequest, > > PLAINBindRequest, SASLBindRequest. I assume that anonymous won't work. > > Maybe I need to request the kadmin/changepw ticket requested above > > using Kerberos and use this to bind to LDAP? > > > > Is there any documentation related to all this? Anything would be > > great but if there's anything related to the way it works in FreeIPA > > that would be even better. I've been searching high and low and I'm > > not really having much luck. > > What have you used so far ? Simple auth ? 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] FreeIPA as a password backend to Samba
On Thu, 2009-12-03 at 10:14 -0600, Michael Wisniewski wrote: > Hi, > > I've discovered that back in September, a user was attempting to use > FreeIPA as a password backend to Samba. I've followed the > instructions from Loris, but ran into a problem. Whenever I create a > new group, I get the following error through the web interface... > > > Group add failed: A database error occurred > Object class violation. missing attribute "sambaGroupType" required by > object class "sambaGroupMapping" > > If I use the command line 'ipa-addgroup', I get a similar error. It looks like sambaGroupType is a required attribute for the sambaGroupMapping objectclass and it is not being added. You need to make sure to add a custom sambaGroupType attribute when you create the group. > However, if I use a ldif and set everything, it works... > > # ldif2ldap "cn=Directory manager" /tmp/s1.ldif > # cat /tmp/s1.ldif > dn: cn=Cyber,cn=groups,cn=accounts,dc=test,dc=org > objectClass: top > objectClass: groupofnames > objectClass: posixGroup > cn: Cyber > description: Cyber Security Group > gidNumber: 1005 > > Now the strange thing. While I did add the "sambaGroupMapping", I > don't see it when I do a ldapsearch and view the group. Also, if I > add my user to the newly created group and run "id", it doesn't show > up that I belong to that group. That may be due to nscd caching, make sure to reload/restart nscd when you change group memberships if you need to see the result immediately. The default group cache timeout can even be 1h on some system. > If anybody can help me with this, that would be great. Since I'm just > starting, if somebody says FreeIPA v2 has this already, I don't mind > switching to it. v2 is a bit experimental at the moment. It is great if you want to see what's going on and help testing but it is not production ready. 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] LDAP-101
On Tue, 2009-12-08 at 09:09 -0600, Michael Wisniewski wrote: > On Tue, Dec 8, 2009 at 8:58 AM, Rob Crittenden wrote: > > > > Schema is sort of a 2-step process. Step 1 is to tell the directory server > > about the schema at all. This can be done offline by dropping a schema file > > into a filesystem directory or online by uploading the schema. Either way > > this just tells the LDAP server about the new objectclasses and attributes > > available and their syntaxes. > > Thanks for the response. Another related question. Does freeipa > 1.2.2 use the "cn=config" way, or the schema file in > /etc/openldap/schema? > > Again, I'm just starting out, but I found configuration information in > both places. I'm just wondering if I were to extend the schema for > use with samba, do I want to go the cn=config route, or the > /etc/openldap/schema file route. FreeIPA uses 389DS as LDAP server not openldap. All the schema files for each instance can be seen under /etc/dirsrv//schema and also by quering the schema online. cn=config can be accessed by the Directory Manager to see or change configuration settings on the fly. Some apply immediately, some other changes may require a DS restart. 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] Re: Configuring Client SSH Access Problem
On Wed, 2009-12-09 at 15:16 +0800, Michael Kang wrote: > Does anyone know what's wrong? > > On Tue, Dec 8, 2009 at 12:35 PM, Michael Kang > wrote: > Dear all, > > I had setup a FreeIPA server and a FreeIPA client. After using > the ktutil command to import the keytab, using the following > command on another machine to test the configuration. This > still need passwd. > > IPA Server: > kinit admin > ipa-addservice host/ipaclient.example.com > ipa-getkeytab -s ipaserver.example.com -p > host/ipaclient.example.com -k /tmp/krb5.keytab > scp /tmp/krb5.keytab > r...@ipaclient.example.com:/tmp/krb5.keytab > > IPA client: > # ktutil > ktutil: read_kt /tmp/krb5.keytab > ktutil: write_kt /etc/krb5/krb5.keytab > ktutil: q > ssh ad...@ipaserver.example.com (This don't need passwd.) > > > PC or Mac: > ssh ad...@ipaclient.example.com (This still need passwd.) So you did successfully kinit on the PC and on the Mac ? You can get more info on what is going on by using ssh -vvv 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] Cross realm authentication
On Fri, 18 Dec 2009 12:31:44 -0500 Dan Scott wrote: > So clients in A.EXAMPLE.COM should be able to authenticate to > C.B.EXAMPLE.COM, but not the other way around (This is how I would > like it setup). > > However, this does not appear to work. I assume that I need to add > some entries to the LDAP server as well? Does anyone know if this is > true and if so, how I should go about it? There are 2 things to consider when cross realm trust are involved. 1. certainly a correct setup so that clients can successfully perform authentication. See Nalin remarks on that. 2. The second is that in order to login on a system you need, not only a successful authentication but an actual user (with uid,gid,home,shell info) the system can associate to your successful authentication. Unless you are interested only in something like http auth which can work w/o real system users. This second part requires a way to provide the other realm users to your system. At the moment we do not have any automated mechanism in FreeIPA itself or in the client to provide that. We will work on these features next year. 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] AD user intergration with IPA
On Mon, 11 Jan 2010 10:58:17 +0300 Shan Kumaraswamy wrote: > Dear All, > > Can any of one could provide me the detail steps of how the AD > accounts would be granted root privileges on RHEL servers using IPA? > > Thanks in Advance. > > Regards, > > Shan Kumaraswamy The best way is to provide sudo access for the users you want to grant root privs to. 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] FreeIPA master replica generation divorce?
On Tue, 12 Jan 2010 15:01:32 -0800 root wrote: > Thinking outside of the box for a moment, is it possible to divorce > the FreeIPA "master" feature of deploying FreeIPA servers from the > FreeIPA cluster which handles everything else? Keeps it safe and out > of harms way, especially considering it has the CA key on it. > > This could be done a couple of different ways. One would be to just > have the master FreeIPA "server" deployed as a VM instance -- we only > dust it off and start it up when a new server needs deployment, and > shut it back down after it's generated the replica file. While crude > for my environment, this would work really well for a VM based shop. No, I think you can't "start it up" only "when needed". Replication would be compromised, the backlog window is about a week IIRC. But what you could do is to keep the first master reachable only by other replicas through firewalling/vpn/vlans your choice. And expose to the real world only the replicas. In this scenario you can shut it down without much care because it is not serving clients. But you cannot keep it shut for long times or it will get completely out of sync with the other replicas. Of course, as Rob already pointed out, you may want to add replication channels between replicas so that your master server is not critical for replication if you have to shut it down. 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] DNS replica setup problem
On Mon, 1 Feb 2010 10:57:35 -0800 Scott Kaminski wrote: > What is it that i'm missing here? Anything in /etc/hosts ? 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] loadbalancer?
On Fri, 22 Jan 2010 11:35:22 -0800 Doug Chapman wrote: > We're currently running SunDS and using Citrix (Netscaler) load > balancers to keep the load on our client facing LDAP servers balanced > between 2 hosts. > > I'm evaluating FreeIPA and wondered if anyone can share any > experience with using IPA behind a load balancer (or point me at > wikidocs)? > > I know the ldap portion will work, it's the kerberos bits I'm > unfamiliar with. Note, this would only be for client connections, > not replication. Hi Doug, sorry for not replying earlier, I'd missed this message. With krb5 you only have a problem if you wan to use SASL/GSSAPI to authenticate LDAP clients to your servers. That's because clients need to acquire a ticket for the server their are going to connect, but you basically lie to clients by using a load balancer and changing target server without their knowledge. so clients will try to acquire a ticket in the name of the balancer (assuming you created a principal for it) and when they reach the server the server will not be able to use it. If you are not planning to use SASL/GSSAPI to authenticate clients to the LDAP server there should be no other issues. Note that in v2 with sssd as a client we assume we can use SASL/GSSAPI by default, but with current clients/freeipa server we don't. 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] Needed_Preauth Issue
On Mon, 08 Mar 2010 18:15:05 -0600
David Christensen wrote:
> I have two servers that I have installed the ipa-client on, both of
> these servers are configured the same way however one is providing
> single sign on, the other is not and instead prompts for a password
> when a user logs in
>
> I did verify that DNS is configured correctly for both servers. I
> issue kinit prior to logging into either server and verified that I
> have a valid ticket for both servers, but the failing server remains
> unchanged. When I look at the krb5kdc.log I see the following for the
> server that is prompting for a password:
>
> Mar 08 23:25:53 ipa1.example.net krb5kdc[12320](info): AS_REQ (12
> etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.200.3.131:
> NEEDED_PREAUTH: dav...@example.net for
> krbtgt/example@example.net, Additional pre-authentication required
>
> Mar 08 23:25:53 ipa1.example.net krb5kdc[12320](info): AS_REQ (12
> etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.200.3.131: ISSUE:
> authtime 1268090753, etypes {rep=18 tkt=18 ses=18},
> dav...@example.net for krbtgt/example@example.net
>
> Where else should I look to find the root cause of this issue? What
> typically causes this type of symptom?
NEEDED_PREAUTH is perfectly natural, you have it for every principal as
it is our default. If you don't see your client requesting a ticket for
host/@EXAMPLE.NET then that is going to be an issue.
If you obtained a ticket for your server and it still falls back to
password auth I suggest looking at the server's logs.
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] MemberOf plugin keeps disabling account
On Wed, 17 Mar 2010 14:01:47 -0400 James Roman wrote: > > > Well, the current 389 memberOf is a bit more advanced than the > > ipa-memberOf. We did the initial development of the plugin, then it > > got moved into mainline 389-ds. The ipa plugin should work fine > > though, I don't know of any reason to switch. > > > > rob > Any idea why both are being executed? Even when the MemberOf Plugin > is disabled? > > # ipa-memberof, plugins, config > dn: cn=ipa-memberof,cn=plugins,cn=config > .. > nsslapd-pluginEnabled: on > > > # MemberOf Plugin, plugins, config > dn: cn=MemberOf Plugin,cn=plugins,cn=config > .. > nsslapd-pluginEnabled: off > > Is it possible that the DS upgrade steps on the ipa-memberof > libraries in some way, causing both to be executed? I would imagine > that having two plugins making the same update to the directory could > be problematic. Maybe its the way the audit logging is occurring. To actually disable the plugin you need a restart after you change the config, but please *do not* do that unless you want trouble :) The memberof plugin does not change group memberships it only updates the memberof attribute to keep it in sync with the member ones. 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] MemberOf plugin keeps disabling account
On Wed, 17 Mar 2010 15:24:18 -0400 James Roman wrote: > > > To actually disable the plugin you need a restart after you change > > the config, but please *do not* do that unless you want trouble :) > > > > The memberof plugin does not change group memberships it only > > updates the memberof attribute to keep it in sync with the member > > ones. > > > > Simo. > > > > > Just to clarify, we never disabled the 389 MemberOf plugin. My > original ldif dump after the upgrade to 1.2.5 had the 389 DS memberOf > plugin disabled. So it never was enabled. This probably meant little > to us from a functional standpoint because we already had the FreeIPA > ipa_memberof plugin installed and enabled. > > Do I need both of them enabled? Or will that cause additional misery? > Of the two, ipa-memberof and 389's memberOf plugin, which should I > enable? > Oh sorry, no I misunderstood. You can't have both enabled they would interfere, only one or the other. The 389 memberof plugin is probably better now, as we merge all the code we developed for ipa in there. But unless you have specific problems you can just leave it as it is. 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] Password Attribute Syncing Support
On Thu, 18 Mar 2010 19:47:35 -0400 Walter Meyer wrote: > Sorry I should have linked to the manual for it: > http://www.postini.com/webdocs/gads/admin > > The Google Apps utility actually syncs passwords from LDAP to Google > Apps, not the other way around. The manual says that the utility > supports password attributes in MD5, SHA1, or Clear Text. So I am > wondering how they are stored in the IPA DS. By default we use Salted SHA (SSHA) for the userPassword attribute. You can change it by changing the passwordStorageScheme attribute (see chapter 7 of the directory server guide), but you will probably have to perform a password change for each user that needs synchronization if you already have passwords set, because the hash can be changed only when the clear text password is available. I have to say though that MD5/SHA1 are considered weak today, esp MD5. Also you should make sure you understand the implication of exposing your internal passwords over the network. By using the same hash for google apps it means you users will send their IPA password to google for authentication (hopefully over HTTPS) so if someone can phish or mitm them they will have the right password for both google apps *and* your company resources. 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] Is sssd currently useable with freeipa v2 ?
On Sat, 01 May 2010 22:43:22 -0400 Rob Crittenden wrote: > The default configuration in hbac uses the model "denied unless > explicitly allowed" which is why all your logins failed. We don't > currently have any default rules set up, I wonder if we should have > some basic ones for demonstration purposes and to sort of bootstrap > things. I think we should have a default *explicit* permit all rule that admins will promptly remove as soon as they have decided what is their final configuration. Otherwise it will make things too nasty for people that are setting it up for the first time. 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] Give laptops bidirectional anywhere access to freeipa and /home/
On Wed, 12 May 2010 12:24:00 -0500 Rob Townley wrote: > The main difference between tinc vpns and traditional vpns is that > tinc is bidirectional and does not require the user to enter a > username password. So if the computer is turned on, the remote > machine is reachable by the IT department. If it is a windows > machine, you may want to verify antivirus signatures are up-to-date. > FusionInventory could be used to push software. > > Yes, it is a machine level as opposed to user level vpn. tinc would > have to run all machines to make it the easiest to use. With freeipa, > that could be easy. > > The keys currently are RSA public / private keypairs. > > Does not have existing code to work with ldap / kerberos as far as i > know. Looks interesting, do you know what's the difference between tinc and something like openvpn ? Is it just the fact that tinc allows inbound connections, or is there more ? 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] Give laptops bidirectional anywhere access to freeipa and /home/
On Wed, 26 May 2010 03:40:33 -0500 Rob Townley wrote: > Tinc does not have a common shared secret between peers but that would > probably be an improvement to make it more like the hamachi vpn. If > both nodes do not have each other's public key host file, they should > not be able to communicate when tinc is in strict mode. In order to > receive something from another tinc node, you would need to trick the > remote node into getting your tinc host key file. Probably not all > that hard of a trick, but a good reason to have central management of > a mesh network. > > Tinc-vpn does not use a Certificate Authority nor X.509, so that is a > weakness of tinc on a large scale.Each tinc node uses a host > text file containing a RSA public key that needs to be distributed > manually to each node if using a strict (tinc version 1.13) > connection configuration. The mesh nature in a less strict / less > secure config allows nodes to connect to other nodes that it does not > have a public certificate for by connecting to an intermediate node. > > A central management point such as available in freeIPA or > ocsinventory-ng would make tinc more favorable. If tinc used kerberos as an optional authentication method then it would not even need the additional RSA public/private key pairs. All it would need is to have a host keytab and access to the FreeIPA server to get a ticket for the other machine. At that point you have mutual authentication and blessing from the KDC. The only downside is that p2p connection wouldn't work if the central server is not reachable at all, but that's probably ok. Anyway, this is a very interesting idea, if someone wants to play with it I am willing to lend a hand to help the effort. Although at the moment we do not have time/resources to start an effort on our own, we may reconsider this after we get 2.0 out of the door. 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] NFS4 after client upgrade to Fedora 13
On Wed, 26 May 2010 20:09:16 +0200 Thomas Sailer wrote: > Hi, > > After upgrading one IPA client from Fedora12 to Fedora13 (the server > runs Fedora12), I'm experiencing NFS4 problems. > > I can still mount the server from the client like this: > mount -t nfs4 -o soft,intr,rsize=8192,wsize=8192,rw,sec=krb5p > server.xxx.com:/home /tmp/z root can then successfully list > subdirectories with ls /tmp/z. However, when a normal user tries to > do this, he gets -EACCES. > > Permissions of /tmp/z should be ok: > > # ls -ldZ /tmp/z > drwxr-xr-x. root root system_u:object_r:nfs_t:s0 /tmp/z > > # getfacl /tmp/z > getfacl: Removing leading '/' from absolute path names > # file: tmp/z > # owner: root > # group: root > user::rwx > group::r-x > other::r-x > > # nfs4_getfacl /tmp/z > A::OWNER@:rwaDxtTcCy > A::GROUP@:rxtcy > A::EVERYONE@:rxtcy > > It worked under Fedora 12. Does anybody have an idea what went wrong? Tom, if you have only a DES key in your keytab for NFS (and you do if you used in in F12 as NFS supported only DES) then you probably see the effect of the new kerberos libraries disallowing DES. Try adding allow_weak_crypto = true to your krb5.conf or alternatively rekey your NFS credentials to add RC4/AES keys (rekeying works only if both client and server kernels supporting anything but DES, I think F13's kernels should have those patches now, but old kernels support only DES). 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] NFS4 after client upgrade to Fedora 13
On Thu, 27 May 2010 12:27:49 -0400 Simo Sorce wrote: > Tom, apologies, I meant Thomas, not enough sleep I gues :/ 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] NFS4 after client upgrade to Fedora 13
On Thu, 27 May 2010 19:13:47 +0200 Thomas Sailer wrote: > On Thu, 2010-05-27 at 12:27 -0400, Simo Sorce wrote: > > > Try adding allow_weak_crypto = true to your krb5.conf or > > alternatively rekey your NFS credentials to add RC4/AES keys > > (rekeying works only if both client and server kernels supporting > > anything but DES, I think F13's kernels should have those patches > > now, but old kernels support only DES). > > Thanks for the hint! Unfortunately, it does not help. I've put > allow_weak_crypto=true in the libdefaults section, but I still get > permission denied when trying to access the mount directory as > non-root. > > However, I got my rawhide machine connecting to the IPA server that > way :) > > I think allow_weak_crypto is only necessary for krb5 1.8 and later, > while F13 still has 1.7. Oh right, then I guess you need to look into syslog to see if you can find any other hint. does the gssd daemon log anything ? 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] NFS4 after client upgrade to Fedora 13
On Thu, 27 May 2010 23:58:28 +0200 Thomas Sailer wrote: > For some reason I have no clue about, it does not like my credentials > cache (/tmp/krb5cc_1591) when not run from the console. I suspect an SELinux issue in this case, because manually starting it will run it as unconfined. Can you check /var/log/audit/audit.log ? 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] Problem with FreeIPA and Samba 3...
On Wed, 16 Jun 2010 21:41:08 +0200 Stjepan Gros wrote: > Hi all, > > I'm trying to integrate Samba 3 into FreeIPA domain. After following > the instructions given in this mailing list > (http://www.mail-archive.com/freeipa-users@redhat.com/msg00111.html) > I'm unable to add new users. The ipa-adduser command complains with > the following error message: > > A database error occurred: Object class violation: missing attribute > "sambaSID" required by object class "sambaSamAccount" > > It seems as if ipa-dna plugin isn't working, i.e. isn't adding > sambaSID attribute. > > Here are the relevant entries from LDAP (with mangled domains): > > dn: cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > objectClass: top > objectClass: nsSlapdPlugin > objectClass: extensibleObject > objectClass: nsContainer > cn: Distributed Numeric Assignment Plugin > nsslapd-pluginInitfunc: dna_init > nsslapd-pluginType: preoperation > nsslapd-pluginEnabled: on > nsslapd-pluginPath: libdna-plugin > nsslapd-plugin-depends-on-type: database > nsslapd-pluginId: Distributed Numeric Assignment > nsslapd-pluginVersion: 1.2.5 > nsslapd-pluginVendor: 389 Project > nsslapd-pluginDescription: Distributed Numeric Assignment plugin > > # sambaGroupType, Distributed Numeric Assignment Plugin, plugins, > config dn: cn=sambaGroupType,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config > objectClass: top > objectClass: extensibleObject > cn: sambaGroupType > dnatype: sambaGroupType > dnainterval: 0 > dnamagicregen: ASSIGN > dnafilter: (objectClass=sambaGroupMapping) > dnanextvalue: 2 > > # SambaSid, Distributed Numeric Assignment Plugin, plugins, config > dn: cn=SambaSid,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config > objectClass: top > objectClass: extensibleObject > dnatype: sambaSID > dnaprefix: S-1-5-21-2932961863-1130097162-856551529 > dnainterval: 1 > dnamagicregen: assign > dnafilter: > (|(objectclass=sambaSamAccount)(objectclass=sambaGroupMapping)) > dnascope: dc=example,dc=com > cn: SambaSid > dnanextvalue: 15277 > > Can someone sched ligth on what's going on, or how to debug these > problems? In the log files (/var/log/dirsrv/dirsrv-EXAMPLE-COM) there > is nothing useful. > > SG > > P.S. dnaprefix has to end with hyphen, but I don't believe it's the > problem. It is not, the instructions in that thread are wrong. We already debugged them with another user, and there are quite a few things that need to be changed. First of all sambaGroupType is a fixed value, not a counter, so the DNA configuration for it just need to be removed. Second, in IPa v1.2.2 we are still using the embedded DNA plugin, so the DNS in that configuration are incorrect for v1.2.2, the DN to be used IIRC is cn=ipa-dna,cn=plugins,cn=config There may be something else we found I am missing, but these 2 are pretty fundamental things. 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] Problem with FreeIPA and Samba 3...
On Thu, 17 Jun 2010 11:38:45 +0200 Stjepan Gros wrote: > First, thank you for your help. It saves me a lot of time. And I hope > that I'll document the whole procedure for the others. One important > general question. Are there any changes in FreeIPA 2 that will > invalidate all this procedure? It will not invalidate it, but in v2 we use the plugin provided from DS directly aqnd do not build our own version anymore so the DN of the config changes to the one you were using before. > Back to the main problem, I removed the entries for DNA that were in a > wrong place and after adding DNA configuration for sambaSID in > cn=ipa-dna,cn=plugins,cn=config I can now add users. All the samba > related attributes are added to a new user after I set initial > password. > > But I can not login using smbclient because samba thinks that the > password is expired. Either I have to set X in samba flags (password > never expires) or I have to properly initialize password related > fields for samba. Setting password fields would be preferable, is it > possible and how? > > Easier way (and necessary in case of groups) is to set fixed value > when creating new users and groups. The question is, is it possible to > configure DNA plugin to set fixed value, or there is specialized (or > more appropriate) plugin for that? Unfortunately in v1.x we didn't have enough infrastructure to make it easier to set additional attributes beyond the default one we set on user/group creation. v2.x should make this possible. 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] SSSD Cache
On Tue, 29 Jun 2010 16:51:39 -0400 Dan Scott wrote: > Hi, > > I'm using Fedora 13 with the new SSSD daemon (Which conflicts with the > old nscd daemon). Does anyone know how to clear the cache of this > service? > > I've added a user to a few groups and "id username" shows the correct > groups on the FreeIPA server, but not on my client machine. I used to > run "/etc/init.d/nscd reload" for nscd, but this does not appear to > work for sssd. > > I've read through the SSSD howto: > > https://fedorahosted.org/sssd/wiki/HOWTO_Configure_1_0_2 > > but this does not mention clearing the cache - only how to set the > cache timeouts. Dan, SSSD will update the cache on any login that goes through PAM. Do you need a way to refresh specific user information it logs in ? If so, at the moment you can reset the cache by stopping SSSD and deleting the appropriate file in /var/lib/sss/db and restarting SSSD. The db file to be deleted has the domain name (as used in the sssd.conf section tag) in the file name. 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] SSSD Cache
On Wed, 30 Jun 2010 15:39:48 -0400 Dan Scott wrote: > This has worked, now the client reports that user belongs to the > correct groups. It also appears to correctly refresh the cache when I > login. I have added and removed my user from a few groups and this is > correctly reflected by the results of the 'id' command. Ok this is the expected behavior. > Maybe the cache was corrupted? Unlikely, maybe your SSSD went offline and wasn't able to get back online for some reason until you restarted 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] about kpasswd on freeIPA
On Sat, 17 Jul 2010 09:36:42 +0700 Gugi Gustaman wrote: > I am a newbie with Kerberos and i need help. > I have a Kerberos installed on my server and it is configured by > freeIPA. When i make an IPA-user, the kerberos password always > expires. And then i tried to doing kinit with that user and kerberos > forced me to change the password because it has expired. And then i > tried some password to change the expired password but i couldn't and > kerberos told me that it rejected my new password. After three times > i tried to change the password, the kinit command finished with error > message like this "kinit : Password change failed while getting > initial credentials". I don't know how to solve this problem and I > need help. > > A week after i made that IPA user, i could doing kinit with that user > (after kerberos asked for the password and forced me to change the > password, the password was accepted and i could doing kinit). But > after I tried to make new IPA user, i met the same problem with the > problem above (Expired kerberos password). Please help me. > > I am sorry with my English, but I am an Indonesian. About password expiration on user creation, that is the normal behavior and here you can read an article that explains the feature: http://freeipa.org/page/NewPasswordsExpired For your other problem I am not sure, keep in mind that FreeIPA has a default password complexity policy that requires you to use a strong password. If you don't like that you will have to alter and relax the password policies. 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] SSS problems with eDirectory
On Thu, 22 Jul 2010 11:10:25 -0400 Scott Duckworth wrote: > I removed all files from /var/lib/sss/db/ and restarted sssd. Same > behavior. nscd is disabled, so I don't think it's caching at any > level. > > Here is what I ran: > > [r...@duck2 ~]# getent passwd sduckwo > sduckwo:*:45265:1:Scott Duckworth:/home/sduckwo:/bin/bash > [r...@duck2 ~]# groups sduckwo > sduckwo : cuuser > [r...@duck2 ~]# getent group coes_socunix > coes_socunix:*:120105:sduckwo When enumeration is disabled this is the normal behavior. You will see only users/groups that have been fetched. Generally at login time because of the initgroups call. Ie a users will always have correct memmberships, but groups may not should all user members they truly have in the ldap server. If you require perfect representation you will have to turn on enumeration. This will eventually show up all the memberships although on the first startup it may take a while to show all groups, until they have all been downloaded and cached. Changes to group memberships may also take some time to show as enumerations are scheduled periodically and results cached. Of cours when a user logs in its information (including its group membership) is refreshed and validated, so at login time the membership is correctly updated for that user across all its groups. 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] SSS problems with eDirectory
On Thu, 22 Jul 2010 15:30:23 -0400 Scott Duckworth wrote: > On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce > wrote: > > > On Thu, 22 Jul 2010 11:10:25 -0400 > > Scott Duckworth wrote: > > > > > I removed all files from /var/lib/sss/db/ and restarted sssd. > > > Same behavior. nscd is disabled, so I don't think it's caching > > > at any level. > > > > > > Here is what I ran: > > > > > > [r...@duck2 ~]# getent passwd sduckwo > > > sduckwo:*:45265:1:Scott Duckworth:/home/sduckwo:/bin/bash > > > [r...@duck2 ~]# groups sduckwo > > > sduckwo : cuuser > > > [r...@duck2 ~]# getent group coes_socunix > > > coes_socunix:*:120105:sduckwo > > > > > I should add to this, that what I expected to see is this (from one > of the RHEL boxes using nss_ldap): > > [r...@potter commands]# groups sduckwo > sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx If you log in as sduckwo you should just see that. The same if you do "id sduckwo" > In other words, I don't so much care that all members of the group are > represented, but rather that all groups of which a user is a member > are represented. > > When enumeration is disabled this is the normal behavior. > > You will see only users/groups that have been fetched. Generally at > > login time because of the initgroups call. > > Ie a users will always have correct memmberships, but groups may not > > should all user members they truly have in the ldap server. > > > > If you require perfect representation you will have to turn on > > enumeration. This will eventually show up all the memberships > > although on the first startup it may take a while to show all > > groups, until they have all been downloaded and cached. > > Changes to group memberships may also take some time to show as > > enumerations are scheduled periodically and results cached. > > > > There are almost 120,000 users in our directory, and we currently > have ~200 Linux systems that might use SSSD, soon scaling to >500 > systems. I imagine that even 500 systems is only a medium-scale > installation compared to some sites. > > Client-side, it's taking 100% of one core (Core i7) at least 45 > minutes (so far) to do the enumeration (the first time around I had > logging enabled and it got up to ~13000 users in ~10 minutes, but > decided to disable logging to reduce processing). Meanwhile, all > other NSS queries using SSSD are blocking and timing out after a few > minutes, apparently waiting on the enumeration to finish. > > I'm not sure what's happening server-side, but I can just see the > directory administrators breathing down our neck if we unleashed > 200-500 systems to enumerate every user at the same time. We completely discourage enableing enumeration in bi sites, that's why it is disabled by default. > Even with caching in effect, I respectfully question this design > decision. What was wrong with the design of nss_ldap and > pam-nss-ldapd to query the directory for group membership for a > single user upon login, then cache it locally? This is exactly what we do. Although we currently are trying to do a little too much on initgroups and trying to save all user members for groups we retrieved. We are going to change initgroups to not request group members for the groups we are interested in. > Of cours when a user logs in its information (including its group > > membership) is refreshed and validated, so at login time the > > membership is correctly updated for that user across all its groups. > > > > This seems to contradict your statement above, and also the behavior > I'm seeing. It's not picking up secondary group memberships unless > they've already been cached, either through an explicit getent or, > presumably (if it ever finishes), via enumeration. Your configuration showed that enumeration is disabled (as it should be), have you changed that ? If you are witnessing long dealys on login then you are hitting the initgroups problem we are going to fix shortly. 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] SSS problems with eDirectory
On Thu, 22 Jul 2010 16:22:45 -0400 Scott Duckworth wrote: > On Thu, Jul 22, 2010 at 3:39 PM, Simo Sorce wrote: > > > On Thu, 22 Jul 2010 15:30:23 -0400 > > Scott Duckworth wrote: > > > > > On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce > > > wrote: > > > > > > > On Thu, 22 Jul 2010 11:10:25 -0400 > > > > Scott Duckworth wrote: > > > > > > > > > I removed all files from /var/lib/sss/db/ and restarted sssd. > > > > > Same behavior. nscd is disabled, so I don't think it's > > > > > caching at any level. > > > > > > > > > > Here is what I ran: > > > > > > > > > > [r...@duck2 ~]# getent passwd sduckwo > > > > > sduckwo:*:45265:1:Scott Duckworth:/home/sduckwo:/bin/bash > > > > > [r...@duck2 ~]# groups sduckwo > > > > > sduckwo : cuuser > > > > > [r...@duck2 ~]# getent group coes_socunix > > > > > coes_socunix:*:120105:sduckwo > > > > > > > > > > > I should add to this, that what I expected to see is this (from > > > one of the RHEL boxes using nss_ldap): > > > > > > [r...@potter commands]# groups sduckwo > > > sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx > > > > If you log in as sduckwo you should just see that. > > The same if you do "id sduckwo" > > > > No go... > > [r...@duck2 ~]# service sssd stop > [r...@duck2 ~]# rm -f /var/lib/sss/db/* > [r...@duck2 ~]# service nscd stop > [r...@duck2 ~]# service sssd start > Starting sssd: [ OK ] > [r...@duck2 ~]# id sduckwo > uid=45265(sduckwo) gid=1(cuuser) groups=1(cuuser) > [r...@duck2 ~]# su - sduckwo > [16:05:24] sduc...@duck2:~ [1] id > uid=45265(sduckwo) gid=1(cuuser) groups=1(cuuser) > [16:05:26] sduc...@duck2:~ [2] groups > cuuser Uhmmm this may be a side effect of your directory not having memberof I think we need to add special code to handle servers that use rfc2307bis schema but that do not use memberof. > I'm unable to actually login due to pam_sss not working (see another > branch of this thread). Yes, I think we need to file a few bugs and add support for servers like yours. > > Of cours when a user logs in its information (including its group > > > > membership) is refreshed and validated, so at login time the > > > > membership is correctly updated for that user across all its > > > > groups. > > > > > > > > > > This seems to contradict your statement above, and also the > > > behavior I'm seeing. It's not picking up secondary group > > > memberships unless they've already been cached, either through an > > > explicit getent or, presumably (if it ever finishes), via > > > enumeration. > > > > Your configuration showed that enumeration is disabled (as it should > > be), have you changed that ? > > > > I did enable enumeration per what I thought was your previous > suggestion. I've now disabled it again. To be clear, my current > sssd.conf is: > > [sssd] > config_file_version = 2 > reconnection_retries = 3 > sbus_timeout = 30 > services = nss, pam > domains = CLEMSONU > [nss] > debug_level = 7 > filter_groups = root > filter_users = root > reconnection_retries = 3 > entry_cache_timeout = 1 > entry_cache_nowait_timeout = 1 > [pam] > debug_level = 7 > reconnection_retries = 3 > [domain/CLEMSONU] > debug_level = 20 > enumerate = False > cache_credentials = False > id_provider = ldap > auth_provider = ldap > ldap_schema = rfc2307bis > chpass_provider = ldap > min_id = 1000 > ldap_uri = ldaps://clemsonuldap.clemson.edu > ldap_id_use_start_tls = False > ldap_tls_cacertdir = /etc/openldap/cacerts > tls_reqcert = demand > ldap_default_bind_dn = cn=CoESProxy,ou=proxyUsers,o=CLEMSONU > ldap_default_authtok_type = password > ldap_default_authtok = xx > ldap_search_base = ou=SoC,ou=CES,o=CLEMSONU > ldap_user_search_base = o=CLEMSONU > ldap_group_search_base = o=CLEMSONU > ldap_user_shell = coesLoginShell > ldap_user_gecos = fullName > ldap_user_fullname = fullName > ldap_pwd_policy = none > > and /etc/openldap/ldap.conf is: > > DEREF always > URI ldaps://clemsonuldap.clemson.edu > BASE ou=SoC,ou=CES,o=CLEMSONU > TLS_CACERTDIR /etc/openldap/cacerts > > > > If you are witnessing long dealys on login then you are hitting the > > initgroups problem we are going to fix shortly. > > > > I believe the long delays were caused by enumeration. There are no > such delays with enumeration disabled. yes, it is expected that enumeration is quite heavy, as it has to query all users and groups and cache that information. That's why we disable it by default. 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] SSS problems with eDirectory
On Thu, 22 Jul 2010 17:59:03 -0400 Dmitri Pal wrote: > [snip] > > Uhmmm this may be a side effect of your directory not having > > memberof I think we need to add special code to handle servers that > > use rfc2307bis schema but that do not use memberof. > > > > > > Are we sure that this is the case? > Is there any chance we can get a schema file that shows what is the > schema used on the server? > May be it is one of the early drafts of the rfc2307bis that is > implemented in the server? > > I think the ldapsearch results listing any one user and a group he is > a member in your server of will be very helpful. > memberof is not required by rfc2307bis. Actually it is not even mentioned by rfc2307bis, so it is our fault if we depend on it. rfc2307bis actually mentions only uniquemember. 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] SSS problems with eDirectory
On Thu, 22 Jul 2010 15:30:23 -0400 Scott Duckworth wrote: > There are almost 120,000 users in our directory, and we currently > have ~200 Linux systems that might use SSSD, soon scaling to >500 > systems. I imagine that even 500 systems is only a medium-scale > installation compared to some sites. Scott, can you tell me roughly how many groups you have, and how big they get up to ? Also do you have nested groups (groups containing other groups) ? 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] SSS problems with eDirectory
On Fri, 23 Jul 2010 17:17:11 -0400 Scott Duckworth wrote: > I've learned that this attribute does exist in our tree, but it's not > being populated when we add users to groups since our proxy user does > not have rights to write groupMembership to users. I'm trying to > find out if we can get our hands on native eDirectory tools that keep > groupMembership of posixAccount and member of posixGroup in sync. > > Still, if groupOf/groupMembership is not required by rfc2307bis, it > would be nice if SSSD did not require it. Yes, we should handle this gracefully, at least through an option. > If a user has a groupOf/groupMembership attribute pointing to a group > outside of ldap_group_search_base, will this be handled gracefully? Yes, the entry will simply be ignored if not resolvable. 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] SSS problems with eDirectory
On Mon, 26 Jul 2010 09:33:22 -0400 Stephen Gallagher wrote: > I was discussing this with Dmitri this morning. I propose that we > should probably do the following: > > After retrieving the user entry, verify whether the entry contains at > least one memberOf attribute. If it does, continue processing as we do > now (since it will be more efficient). If not, then we should slip > into compatibility mode where we will search all groups for > member= > > Does this seem sensible? yes and no. Actually we should really have a switch that tells us whether we fully trust memberof to give us the complete picture (IPA case) or if we should use it only as a hint (AD and servers that do not use memberof at all). In AD for example we currently return only direct memberships because in AD member/memberof are linked attributes, this means memberof does not contains DNs of indirect group memberships. I believe eDirectory is probably the same even when their memberof-equivalent attribute is set (assuming they support nesting at all). Of course we can also have a switch to allow searching for nested groups or not, so that we do not cause unnecessary searches on deployments that do not use any form of nesting. The parameter should actually probably be an integer that determines the level of nesting we allow to search at runtime, with 0 meaning none and any other value up to a maximum we define allowing deeper and deeper nesting. 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] 389-ds to free-ipa transition; transparent?
On Thu, 2 Sep 2010 16:26:26 -0700 Brian LaMere wrote: > > > > 389 access control is pretty powerful and flexible. There's > > usually a way to do what you want to do without having to resort to > > using subtrees (as in AD). > > > > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Managing_Access_Control.html > > > > > aye - I already have everything on that side of the house working > perfectly, in exactly the way I want it. However, part of how I have > that is based on ACIs attached to specific ou units. So if it could > probably be made to work without resorting to ACIs for individual > OUs, then...ok. I want PMs to be able to make people that are > customers, but not people who are People (that sounds horrible, but > you know what I mean...heh). That's just one of example of many, > including batch processes that make changes to specific ou units > reserved for the activities of those processes. > > Perhaps I'll just install FreeIPA and see, then. Brian, for non user/group/host objects you fully own and control you can use whatever directory structure you want as long as you do not put them under the cn=accounts subtree and keep them generally away from any IPA controlled subtree. 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] Kerberos Password change limitation while behind a NAT
On Thu, 30 Sep 2010 16:05:52 +0200 Marc Schlinger wrote: > Hello all, > > I cannot change a expired user password while behind a NAT. > The error I get is: > > kpasswd[6756]: Failed to decrypt password: Incorrect net address > > I believe this is a kerberos limitation due to the difference between > the host ip adress enclosed in the ticket - the host's rfc1918 > address - and the address used to communicate with the server - the > router's address. This setup is very common @home > > There must be a way to disable the verification for kpasswd since it > works for other services. But it may have been set for security > purposes, so disabling it may introduce some flaws. > > I know that ipa passwd can set the password by calling a special > method through xmlrpc, but if the client has no credential, he must > retrieve one - with kinit - before calling this method. And kinit > will ask to change the password. > > My problem is, how can I handle the case where a user has a expired > password and is behind a NAT? You can use ldappasswd too, either with GSSAPI auth or eventually even with plaintext auth (require using SSL) in that case though you will neeed to know the user DN. 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] Supporting multiple seperate kerberos providers
On Thu, 30 Sep 2010 13:54:40 -0500 Dennis Gilmore wrote: > Hi All, > > One thing that some folks in Fedora are evaluating is to integrate > freeipa with fas, this would enable services like koji to gain > kerberos auth, as well as git etc. It could also be enabled on > fedorahosted etc. > > > but it brings to light a deficiency in krb5. while you can define > multiple realms and manually switch between them in various ways. its > not user friendly, and doesnt lend itself to having to frequently > switch between kerberos providers. > > the lacking thing is that you can only cache one tgt at a time. you > can work around this by manually defining different caches or running > kinit each time you need to switch. > > the soultion seems to me to enable krb5 to cache multiple tgt's > personally right now i have 2 kerberos servers i frequently deal > with. 1 for home and one for work, if we end up deploying kerberos > support in fedora ill have 3. and it will get really messy fast. I > can keep things seperate now. but with fedora and work using > kerberos that will be impossible. > > I wanted to throw out there the very real and possible usage senarios > and get some further discussion on how best it will be to handle this > going forward. I guess we should discuss this with the broader kerberos community. In theory credential caches can hold multiple tickets, but the tools (kinit,kdestroy and friends) just do not support it now and tend to wipe out everything. I think I've seen recently something about this so maybe voicing the problem on the "kerberos" (at mit.edu) mailing list may spark a good discussion. On my side I will try to make this problem known to some MIT devs and see what they think. 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] Replica not syncing 'memberOf' attributes
On Wed, 6 Oct 2010 10:26:48 -0400 Dan Scott wrote: > Hi, > > I have master and slave FreeIPA servers. I recently upgraded the slave > by wiping, re-installing Fedora 13 and re-creating the replication > using ipa-replica-prepare and ipa-replica-install. > > For some reason, the slave is having difficulty replicating the > memberOf attribute. I can attach an LDAP viewer to the replica, and > view the schema, but the memberOf attributes are missing. Also, the > master server contains the lines: > > - Entry "cn=admins,cn=groups,cn=accounts,dc=example,dc=com" -- > attribute "memberOf" not allowed > NSMMReplicationPlugin - repl_set_mtn_referrals: could not set > referrals for replica dc=example,dc=com: 20 > NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for > replica dc=example,dc=com does not match the data in the changelog. > Recreating the changelog file. This could affect replication with > replica's consumers in which case the consumers should be > reinitialized. > [06/Oct/2010:09:58:33 -0400] - skipping cos definition cn=account > inactivation,cn=accounts,dc=example,dc=com--no templates found > > The rest of the replication appears to be working correctly (as far as > I can tell). > > I have tried using ipa-replica-manage init and synch to try to fix the > replication, but I suspect this has something to do with the schema > definition. > > Does anyone have any pointers/ideas for how I can fix this? Dan, the memberof attribute is explicitly not replicated, and should be simply re-generated on the receiving replica when "member" attributes are replicated. Are the IPA versions on the master and the replica the same ? 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] Replica not syncing 'memberOf' attributes
On Thu, 7 Oct 2010 10:43:15 -0400 Dan Scott wrote: > Sorry about that, I now get: > > adding new entry cn=memberOf_fixup_2010_10_7_10_41_11, cn=memberOf > task, cn=tasks, cn=config > ldap_add: Insufficient access > > I have an admin Kerberos ticket and I know the password is correct > because otherwise I get 'ldap_simple_bind: Invalid credentials'. > > Thanks, > > Dan Sorry Dan, these kind of task need to be run with "cn=Directory Manager" credentials I am afraid. 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] Replica not syncing 'memberOf' attributes
On Thu, 07 Oct 2010 09:20:29 -0600 Rich Megginson wrote: > > > Does IPA have its own memberOf plugin, or is it using the one from > 389? In v1, it had its own memberof plugin. 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] Secure nfs4 and Fedora 14
On Thu, 11 Nov 2010 13:44:55 +0100 Thomas Sailer wrote: > Since I upgraded about two days ago from a fully up-to-date and > working Fedora13 system to Fedora14, I am unable to mount the krb5p > nfs4 shares of the freeipa server (which is itself running a fully > up-to-date Fedora12). > > rpc.gssd on the client reports the following: > > beginning poll > dir_notify_handler: sig 37 si 0x7fff99e83030 data 0x7fff99e82f00 > dir_notify_handler: sig 37 si 0x7fff99e7f930 data 0x7fff99e7f800 > dir_notify_handler: sig 37 si 0x7fff99e82ef0 data 0x7fff99e82dc0 > handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt38) > handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' > handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt38) > process_krb5_upcall: service is '' > Full hostname for 'server..xxx' is 'server..xxx' > Full hostname for 'clnt..xxx' is 'clnt..xxx' > Key table entry not found while getting keytab entry for > 'root/clnt.@.xxx' Success getting keytab entry for > 'nfs/clnt.@.xxx' Successfully obtained machine > credentials for principal 'nfs/clnt.@.xxx' stored in > ccache 'FILE:/tmp/krb5cc_machine_.XXX' INFO: Credentials in CC > 'FILE:/tmp/krb5cc_machine_.XXX' are good until 1289651734 using > FILE:/tmp/krb5cc_machine_.XXX as credentials cache for machine > creds using environment variable to select krb5 ccache > FILE:/tmp/krb5cc_machine_.XXX creating context using fsuid 0 > (save_uid 0) creating tcp client for server server..xxx DEBUG: > port already set to 2049 creating context with server > n...@server..xxx WARNING: Failed to create krb5 context for user > with uid 0 for server server..xxx WARNING: Failed to create > machine krb5 context with credentials cache > FILE:/tmp/krb5cc_machine_.XXX for server server..xxx WARNING: > Machine cache is prematurely expired or corrupted trying to recreate > cache for server server..xxx Full hostname for 'server..xxx' > is 'server..xxx' Full hostname for 'clnt..xxx' is > 'clnt..xxx' Key table entry not found while getting keytab entry > for 'root/clnt.@.xxx' Success getting keytab entry for > 'nfs/clnt.@.xxx' INFO: Credentials in CC > 'FILE:/tmp/krb5cc_machine_.XXX' are good until 1289651734 INFO: > Credentials in CC 'FILE:/tmp/krb5cc_machine_.XXX' are good until > 1289651734 using FILE:/tmp/krb5cc_machine_.XXX as credentials > cache for machine creds using environment variable to select krb5 > ccache FILE:/tmp/krb5cc_machine_.XXX creating context using fsuid > 0 (save_uid 0) creating tcp client for server server..xxx DEBUG: > port already set to 2049 creating context with server > n...@server..xxx WARNING: Failed to create krb5 context for user > with uid 0 for server server..xxx WARNING: Failed to create > machine krb5 context with credentials cache > FILE:/tmp/krb5cc_machine_.XXX for server server..xxx WARNING: > Failed to create machine krb5 context with any credentials cache for > server server..xxx doing error downcall dir_notify_handler: sig > 37 si 0x7fff99e83030 data 0x7fff99e82f00 dir_notify_handler: sig 37 > si 0x7fff99e83030 data 0x7fff99e82f00 dir_notify_handler: sig 37 si > 0x7fff99e82f30 data 0x7fff99e82e00 dir_notify_handler: sig 37 si > 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si > 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si > 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si > 0x7fff99e7dfb0 data 0x7fff99e7de80 destroying > client /var/lib/nfs/rpc_pipefs/nfs/clnt39 destroying > client /var/lib/nfs/rpc_pipefs/nfs/clnt38 > > I need to downgrade the kernel and krb5* to the Fedora13 version to > get nfs4 working again. > > Does anybody have an idea why it no longer works? > > What is the current party line with respect to nfs4 encryption types? > The admin guide on the freeipa web page still requires des-cbc-crc. > But MIT Kerberos seems to become increasingly hostile against des. > And yes, I do have allow_weak_crypto = true in krb5.conf/libdefaults Starting with F14 you can use any crypto for NFS. However DES should still just work if you have a DES key. This looks like a kernel/rpc.gssd bug, I would file a ticket against those components. 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] krb5 nfs failure between F14 freeipa server and F14 client
On Sat, 04 Dec 2010 10:57:13 +0100
Thomas Sailer wrote:
> Hi,
>
> after upgrading a F12 freeipa server to F14, krb5 nfs no longer works.
>
> 1) ipa-getkeytab works only very unreliably. I get the following
> about 4 out of 5 times:
> # ipa-getkeytab -s 192.168.1.2 -p nfs/client..xxx
> -k /etc/krb5.keytab Operation failed! Unable to set key
>
> ipa-delservice, ipa-addservice and other ipa- commands seem to work
> fine, though.
>
> 2) I get the following log from rpc.gssd on the client:
> # rpc.gssd -f -v -v -v -v -v beginning poll
> dir_notify_handler: sig 37 si 0x7d2a16b0 data 0x7d2a1580
> dir_notify_handler: sig 37 si 0x7d2a16b0 data 0x7d2a1580
> dir_notify_handler: sig 37 si 0x7d2a16b0 data 0x7d2a1580
> handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt1c)
> handle_gssd_upcall: 'mech=krb5 uid=0 '
> handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt1c)
> process_krb5_upcall: service is ''
> Full hostname for 'server..xxx' is 'server..xxx'
> Full hostname for 'client..xxx' is 'client..xxx'
> Key table entry not found while getting keytab entry for
> 'root/client.@.xxx' Success getting keytab entry for
> 'nfs/client.@.xxx' WARNING: Generic error (see e-text)
> while getting initial ticket for principal
> 'nfs/client.@.xxx' using keytab 'WRFILE:/etc/krb5.keytab'
> ERROR: No credentials found for connection to server server..xxx
> doing error downcall dir_notify_handler: sig 37 si 0x7d2a1170
> data 0x7d2a1040 dir_notify_handler: sig 37 si 0x7d2a16b0 data
> 0x7d2a1580 dir_notify_handler: sig 37 si 0x7d2a16b0 data
> 0x7d2a1580 dir_notify_handler: sig 37 si 0x7d2a16b0 data
> 0x7d2a1580 dir_notify_handler: sig 37 si 0x7d2a16b0 data
> 0x7d2a1580 dir_notify_handler: sig 37 si 0x7d2a16b0 data
> 0x7d2a1580 destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt1c
>
>
> 3) In the server's kdc log, I find the following:
> Dec 04 02:09:08 server..xxx krb5kdc[6933](info): AS_REQ (7 etypes
> {18 17 16 23 1 3 2}) 192.168.1.220: LOOKING_UP_CLIENT:
> nfs/client.@.xxx for krbtgt/@.xxx, unable to
> decode stored principal key data (ASN.1 structure is missing a
> required field)
>
> Does anybody have an idea how I could get krb5 nfs working again?
We are seeing an issue with F14 DS where it has been built against
opneldap libraries while we still have plugins built against mozldap.
We have a patch that should be solving some issues against ipav2, if
that checks out we will se if we can backport them to ipa 1.2.2 but it
may take a little while.
Meanwhile you may want to try to downgrade 389-ds (make sure you
backup your data first).
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] krb5 nfs failure between F14 freeipa server and F14 client
On Mon, 06 Dec 2010 18:31:37 +0100 Thomas Sailer wrote: > On Mon, 2010-12-06 at 10:55 -0500, Simo Sorce wrote: > > Hi Simo, > > thanks for your response! > > > We are seeing an issue with F14 DS where it has been built against > > opneldap libraries while we still have plugins built against > > mozldap. > > Where would that help? > just for the ipa-getkeytab reliability issue? Yes, that is probably a side effect of the problem we're solving. > Because after the kerberos keys are in the client's keytab, how is > ldap even involved in the nfs issues? Keys are stored in ldap and asn.1 encoding is generated using ldap libraries before storing it. If that operation fails it may generate malformed entries that the KDC later can't properly decode. 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] krb5 nfs failure between F14 freeipa server and F14 client
On Mon, 06 Dec 2010 19:43:29 +0100 Thomas Sailer wrote: > On Mon, 2010-12-06 at 13:35 -0500, Simo Sorce wrote: > > > Keys are stored in ldap and asn.1 encoding is generated using ldap > > libraries before storing it. > > If that operation fails it may generate malformed entries that the > > KDC later can't properly decode. > > Which patch are you talking about? Is it included in the current alpha > (binaries)? I pushed the patch in git just today :) > Upgrade to the current alpha might be a better idea than > trying to downgrade, or am I overlooking something? V2 will need a migration, upgrades are not really possible as we have added/changed a ton of schema and other things in the LDAP tree. 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] krb5 nfs failure between F14 freeipa server and F14 client
On Tue, 07 Dec 2010 10:51:55 +0100 Thomas Sailer wrote: > On Mon, 2010-12-06 at 13:53 -0500, Simo Sorce wrote: > > Hi Simo, > > > I pushed the patch in git just today :) > > Your patch indeed helps :) > > I've adapted it to the fc14 srpm, compiled it, and at least the extop > plugin now uses the openldap libraries: > http://sailer.fedorapeople.org/ipa-1.2.2-5.fc14.jnx.src.rpm > > The unreliability of ipa-getkeytab seems now gone, and the krb5 kdc > now issues nfs tickets (the ASN.1 parse error is now gone). Great, we will "steal" your port of the patch and release new Fedora packages then :) > However krb5nfs still does not work, it hangs now (instead of giving > me an instantaneous error). Will investigate further. Let us know if you solve this problem. Thank you, 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] Upgraded server from Fedora 13 to 14: Cannot reset user passwords
On Fri, 17 Dec 2010 10:47:06 -0500 Dan Scott wrote: > Hi, > > I have recently upgraded one of our server from Fedora 13 to 14. > Recently, I noticed that I cannot reset user passwords any more: > > A database error occurred: Operations error: Failed to update password > > The log file contains the following entries: > [16/Dec/2010:10:47:08 -0500] ipa_pwd_extop - encoding asn1 > EncryptionKey failed [16/Dec/2010:10:47:08 -0500] ipa_pwd_extop - > encoding asn1 KrbSalt failed [16/Dec/2010:10:47:08 -0500] > ipa_pwd_extop - key encryption/encoding failed > > Packages: > 389-ds-base-1.2.7.4-1.fc14.x86_64 > ipa-server-1.2.2-5.fc14.x86_64 > > This appears similar to a bug reported a couple of weeks ago: > > https://bugzilla.redhat.com/show_bug.cgi?id=658832 > > Although the above report is related to ipa-getkeytab rather than > ipa-passwd. If they are the same issue, then this bug is more serious > since I can't create new users or allow password changes. Yes it is almost certainly the same issue, as the ipa-pwd-exop plugin handles all password changes and keytab issuance. > Does anyone have a status on this? We have a patch for the v2 version of the plugins but haven't yet found the time to backport to 1.2.2. A workaround is to downgrade DS to a version not compiled with openldap libs (or recompile it with mozldap). If you look in this list archives you will also find that Thomas Sailer has created a backport of the patch and posted a srpm on his fedora people page. We hope to address the issue as soon as possible, but we are short on time in this period. 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] Unable to access web interface
- Original Message - > Hi all > > I just noticed that am unable to access the web interface for freeipa. > I had > updated the server 2.0 alpha-5 and then beta version that came out > some days > ago. but since I do not use that web interface I have not idea when I > lost > the web interface ability. Hi Uzor, until the final version will come out we keep making changes to the directory tree that requires a full reinstall. You can probably get the web interface to work, but then most probably you will get weird errors or failures during use. In particular we completely changed the way permissions/privileges/roles are stored/handled between the alphas and the beta. HTH, Simo. > Now, though when I try to get to the web interface from a kerberized > account > all I get is an http error > > "The requested URL /ipa/ui was not found on this server" > > In the httpd error log, all that is there are > > [Tue Dec 28 11:55:29 2010] [error] [client 192.168.17.13] File does > not > exist: /var/www/html/favicon.ico > [Tue Dec 28 11:55:32 2010] [error] [client 192.168.17.13] File does > not > exist: /var/www/html/favicon.ico > > access_log shows: > > 192.168.17.13 - - [28/Dec/2010:11:56:35 -0500] "GET /ipa/ui HTTP/1.1" > 301 > 319 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) > Gecko/20101209 > Fedora/3.6.13-1.fc13 Firefox/3.6.13" > 192.168.17.13 - - [28/Dec/2010:11:56:35 -0500] "GET /ipa/ui HTTP/1.1" > 401 > 1164 > 192.168.17.13 - u...@mydomain [28/Dec/2010:11:56:36 -0500] "GET /ipa/ui > HTTP/1.1" 404 174 > > ssl_error_log is empty > ipa files version are: > ipa-python-2.0.0.pre1-0.fc13. > i686 > ipa-admintools-2.0.0.pre1-0.fc13.i686 > ipa-server-2.0.0.pre1-0.fc13.i686 > ipa-client-2.0.0.pre1-0.fc13.i686 > > All my command line still works. > > Thanks for you help > > Ide > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- --- 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] Unable to change Admin password
On Wed, 12 Jan 2011 13:58:31 -0500
Uzor Ide wrote:
> Hello List
>
>
> We are having problem with changing/reseting password. Even the admin
> password cannot be changed. During login users with expired
> passwords are warned that their password has expired and forced to
> change their password. But when the type new password, the operation
> fails with error "Authentication token manipulation error"
>
> When I tried the change the admin krb5 password from the ipa-server I
> got the following error
> "Cannot contact any KDC for requested realm while getting initial
> credentials"
>
> That's surprising because the KDC hostname resolves properly.
>
> This what's in the krb5kdc.log each time
>
> Jan 12 13:30:27 ipaserver.mycompany.com krb5kdc[1382](info): AS_REQ (7
> etypes {18 17 16 23 1 3 2}) 192.168.1.12: ISSUE: authtime 1294857027,
> etypes {rep=18 tkt=18 ses=18}, ad...@mycompany.com for kadmin/
> chang...@mycompany.com
> Jan 12 13:30:39 ipaserver.mycompany.com krb5kdc[1382](info): AS_REQ (7
> etypes {18 17 16 23 1 3 2}) 192.168.1.12: NEEDED_PREAUTH: kadmin/
> chang...@mycompany.com for krbtgt/mycompany@uzdomain.ca,
> Additional pre-authentication required
> Jan 12 13:30:40 ipaserver.mycompany.com krb5kdc[1382](info): AS_REQ (7
> etypes {18 17 16 23 1 3 2}) 192.168.1.12: ISSUE: authtime 1294857040,
> etypes {rep=18 tkt=18 ses=18}, kadmin/chang...@mycompany.com for
> krbtgt/ mycompany@uzdomain.ca
>
> The server is freeipa-2.0 -beta and O/S is fedora 13
>
> Any help will be greatly appreciated
Is ipa_kpasswd running ?
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] Unable to change Admin password
On Wed, 12 Jan 2011 20:02:14 + ide4...@gmail.com wrote: > Yes ipa_kpasswd is running. > > > Sent on the TELUS Mobility network with BlackBerry Can you check it was able to bind to udp ports ? I just noticed it wasn't able to in my fedora 14, and posted a patch. 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] certificate verify failed - WinSync strangeness - ipa-server-1.2.2-0
On Wed, 12 Jan 2011 12:03:59 -0600 "d...@killbrad.com" wrote: > Ok, so the ipa-server-certinstall script seems to be where things did > not work as I perhaps expected them to. > > I manually put the certificates in the dirsrv cert db, and the web > interface cert db. The ipa-replica-manage uses replication.py, which > is declaring > > CACERT="/usr/share/ipa/html/ca.crt" > > It looks like this is where the error is being caused. The > certification there is still the original "IPA Test Certificate > Authority". If I point it to the DigiCertCA.crt (which should work), > OR the AD-ca.crt file, I get the same error as originally mentioned > when running 'ipa-replica-manage list'. If I comment out the CACERT > variable it does as expected: unexpected error: global name 'CACERT' > is not defined > > So, can someone give me some advice about where else it may be > reading the certificate from, or how I can do things "the proper way" > for IPA? /etc/ipa/ca.crt is another place where the cert can be found. but for winsync you can pass the cacert on the command line, have you tried that ? 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] Freeipa-users Digest, Vol 30, Issue 8
On Wed, 19 Jan 2011 12:52:54 +0530 Aravind GV wrote: > Hi All > > Please help me in adding a synchronization agreement. I followed ( > http://freeipa.org/docs/2.0.0/Installation_Deployment_Guide/en-US/html/) > but the example given in 4.4. Creating Synchronization Agreements is > not correct. There is no more option add in ipa-replica-manage > command. After googling they suggested me to use connect instead of > add. This command worked but it stopped directory server and thorws > following errors. Jakub Hrozek suggested me to get logs > from /var/log/ipareplica-install.log. But this file is not at all > created only ipaclient-install.log ipaserver-install.log are the two > files in that there is no reference to ipa-replica-mange command. > > I have installed ipa v2 from http://jdennis.fedorapeople.org repo. > > [root@dirsrv ~]# ipa-replica-manage connect --winsync --binddn > CN=agv,OU=Users,DC=bgkerb,DC=test02,DC=com --bindpw asd312ASD --cacert > /root/bgkerb.cer 10.0.65.28 -v --passsync asd312ASD > INFO:root:args=/sbin/service dirsrv stop > INFO:root:stdout=Shutting down dirsrv: > AGV-COM...[ OK ] > PKI-IPA...[ OK ] > > INFO:root:stderr= > unexpected error: DsInstance instance has no attribute 'subject_base' I have opened ticket 807[1] to track this. Would you be available to test a patch ? Simo. [1] https://fedorahosted.org/freeipa/ticket/807 -- 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] Freeipa-users Digest, Vol 30, Issue 8
On Wed, 19 Jan 2011 09:28:45 -0500 Simo Sorce wrote: > On Wed, 19 Jan 2011 12:52:54 +0530 > Aravind GV wrote: > > > Hi All > > > > Please help me in adding a synchronization agreement. I followed ( > > http://freeipa.org/docs/2.0.0/Installation_Deployment_Guide/en-US/html/) > > but the example given in 4.4. Creating Synchronization Agreements > > is not correct. There is no more option add in ipa-replica-manage > > command. After googling they suggested me to use connect instead of > > add. This command worked but it stopped directory server and thorws > > following errors. Jakub Hrozek suggested me to get logs > > from /var/log/ipareplica-install.log. But this file is not at all > > created only ipaclient-install.log ipaserver-install.log are the > > two files in that there is no reference to ipa-replica-mange > > command. > > > > I have installed ipa v2 from http://jdennis.fedorapeople.org repo. > > > > [root@dirsrv ~]# ipa-replica-manage connect --winsync --binddn > > CN=agv,OU=Users,DC=bgkerb,DC=test02,DC=com --bindpw asd312ASD > > --cacert /root/bgkerb.cer 10.0.65.28 -v --passsync asd312ASD > > INFO:root:args=/sbin/service dirsrv stop > > INFO:root:stdout=Shutting down dirsrv: > > AGV-COM...[ OK ] > > PKI-IPA...[ OK ] > > > > INFO:root:stderr= > > unexpected error: DsInstance instance has no attribute > > 'subject_base' > > > I have opened ticket 807[1] to track this. > Would you be available to test a patch ? > > Simo. > > [1] https://fedorahosted.org/freeipa/ticket/807 > Can you test this patch and see if it solves your issue completely ? You should be able to manually fix it without having to redo the whole install by simplky editing the dsinstance.py file and adding the line you see in the patch. Simo. -- Simo Sorce * Red Hat, Inc * New York >From a6128d4f7fc21d284ce2d8e154e4f8cdc7d9964d Mon Sep 17 00:00:00 2001 From: Simo Sorce Date: Wed, 19 Jan 2011 09:53:59 -0500 Subject: [PATCH] Initialize subject_base by default. Avoids ipa-replica-manage to throw up errors. Fixes: https://fedorahosted.org/freeipa/ticket/807 --- ipaserver/install/dsinstance.py |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 859d5c8ff737dad3ba96b162e90c7d1bae4e0d11..4fd7a00279c73c5b41e2d7ad5999c1af91eefbf8 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -180,6 +180,7 @@ class DsInstance(service.Service): self.dercert = None self.idstart = None self.idmax = None +self.subject_base = None if realm_name: self.suffix = util.realm_to_suffix(self.realm_name) self.__setup_sub_dict() -- 1.7.3.4 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa-users Digest, Vol 30, Issue 8
On Wed, 19 Jan 2011 22:22:45 +0530 Aravind GV wrote: > Hi Simo, > > Thanks for responding to my email. I > updated /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py > with the patch ie added extra line self.subject_base = None > > Now i am getting different error > > [root@dirsrv ~]# ipa-replica-manage connect --winsync --binddn > CN=agv,OU=Users,DC=bgkerb,DC=test02,DC=com --cacert /root/bgkerb.cer > bgkerb.test02.com --passsync asd312ASD --bindpw asd312ASD -v > Directory Manager password: > INFO:root:args=/sbin/service dirsrv stop > INFO:root:stdout=Shutting down dirsrv: > AGV-COM...[ OK ] > PKI-IPA...[ OK ] > > *INFO:root:stderr=* > *unexpected error: 'Env' object has no attribute 'ra_plugin'* > > > > Regards, > AGV > > On Wed, Jan 19, 2011 at 8:29 PM, Simo Sorce wrote: > > > On Wed, 19 Jan 2011 09:28:45 -0500 > > Simo Sorce wrote: > > > > > On Wed, 19 Jan 2011 12:52:54 +0530 > > > Aravind GV wrote: > > > > > > > Hi All > > > > > > > > Please help me in adding a synchronization agreement. I > > > > followed ( > > > > > > http://freeipa.org/docs/2.0.0/Installation_Deployment_Guide/en-US/html/) > > > > but the example given in 4.4. Creating Synchronization > > > > Agreements is not correct. There is no more option add in > > > > ipa-replica-manage command. After googling they suggested me to > > > > use connect instead of add. This command worked but it stopped > > > > directory server and thorws following errors. Jakub Hrozek > > > > suggested me to get logs from /var/log/ipareplica-install.log. > > > > But this file is not at all created only ipaclient-install.log > > > > ipaserver-install.log are the two files in that there is no > > > > reference to ipa-replica-mange command. > > > > > > > > I have installed ipa v2 from http://jdennis.fedorapeople.org > > > > repo. > > > > > > > > [root@dirsrv ~]# ipa-replica-manage connect --winsync --binddn > > > > CN=agv,OU=Users,DC=bgkerb,DC=test02,DC=com --bindpw asd312ASD > > > > --cacert /root/bgkerb.cer 10.0.65.28 -v --passsync asd312ASD > > > > INFO:root:args=/sbin/service dirsrv stop > > > > INFO:root:stdout=Shutting down dirsrv: > > > > AGV-COM...[ OK ] > > > > PKI-IPA...[ OK ] > > > > > > > > INFO:root:stderr= > > > > unexpected error: DsInstance instance has no attribute > > > > 'subject_base' > > > > > > > > > I have opened ticket 807[1] to track this. > > > Would you be available to test a patch ? > > > > > > Simo. > > > > > > [1] https://fedorahosted.org/freeipa/ticket/807 > > > > > > > Can you test this patch and see if it solves your issue completely ? > > > > You should be able to manually fix it without having to redo the > > whole install by simplky editing the dsinstance.py file and adding > > the line you see in the patch. > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > Attached a corrected patch that should fix this second problem too. Simo. -- Simo Sorce * Red Hat, Inc * New York >From e61bc661f49470b6be509b6187313f70edfa09f9 Mon Sep 17 00:00:00 2001 From: Simo Sorce Date: Wed, 19 Jan 2011 09:53:59 -0500 Subject: [PATCH] Fix ipa-replica-manage regressions with winsync Avoids ipa-replica-manage to throw up errors. Fixes: https://fedorahosted.org/freeipa/ticket/807 --- install/tools/ipa-replica-manage |7 ++- ipaserver/install/dsinstance.py |1 + 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage index 80974545761399cec46032c8ae2b6689aa4ff7fd..20eb93c26748c71e097a38f40cb58c0215a643e1 100755 --- a/install/tools/ipa-replica-manage +++ b/install/tools/ipa-replica-manage @@ -26,7 +26,7 @@ from ipapython import ipautil from ipaserver.install import replication, dsinstance, installutils from ipaserver import ipaldap from ipapython import version -from ipalib import errors, util +from ipalib import api, errors, util CACERT = "/etc/ipa/ca.crt" @@ -355,6 +355,11 @@ def force_sync(realm, thishost, fromhost, dirman_passwd): def main(): options, args = parse_options() +# Just initialize the environment. This is so the installer can have +# access to the plugin environment +api.bootstrap(in_server=True) +api.finalize() + dirman_passwd = None realm = krbV.default_context().def
Re: [Freeipa-users] Freeipa-users Digest, Vol 30, Issue 8
On Thu, 20 Jan 2011 11:03:12 +0530
Aravind GV wrote:
> Hi Simo,
>
> Great repossess from you but still issue is not solved completely.
> After applying your patch iam getting below mention error
>
>
> [root@dirsrv ~]# ipa-replica-manage connect --winsync --binddn
> CN=agv,OU=Users,DC=bgkerb,DC=test02,DC=com --cacert /root/bgkerb.cer
> 10.0.65.28 --passsync asd312ASD --bindpw asd312ASD -v
> Added CA certificate /root/bgkerb.cer to certificate database for
> dirsrv.agv.com
> *unexpected error: basic_replication_setup() takes exactly 5
> arguments (3 given)*
I am sorry Aravind,
but at the moment I do not have a test environment that lets me test
winsync replication.
Hopefully this new patch should fix the remaining regressions.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
>From 5c9952b5e166dde222bc8c5433ca97480432a980 Mon Sep 17 00:00:00 2001
From: Simo Sorce
Date: Wed, 19 Jan 2011 09:53:59 -0500
Subject: [PATCH] Fix ipa-replica-manage regressions with winsync
Avoids ipa-replica-manage to throw up errors.
Fixes: https://fedorahosted.org/freeipa/ticket/807
---
install/tools/ipa-replica-manage |7 ++-
ipaserver/install/dsinstance.py |1 +
ipaserver/install/replication.py |8 +---
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage
index 80974545761399cec46032c8ae2b6689aa4ff7fd..20eb93c26748c71e097a38f40cb58c0215a643e1 100755
--- a/install/tools/ipa-replica-manage
+++ b/install/tools/ipa-replica-manage
@@ -26,7 +26,7 @@ from ipapython import ipautil
from ipaserver.install import replication, dsinstance, installutils
from ipaserver import ipaldap
from ipapython import version
-from ipalib import errors, util
+from ipalib import api, errors, util
CACERT = "/etc/ipa/ca.crt"
@@ -355,6 +355,11 @@ def force_sync(realm, thishost, fromhost, dirman_passwd):
def main():
options, args = parse_options()
+# Just initialize the environment. This is so the installer can have
+# access to the plugin environment
+api.bootstrap(in_server=True)
+api.finalize()
+
dirman_passwd = None
realm = krbV.default_context().default_realm
diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index 378e0123405ed1222129d899573974fba9089a55..5da9d17d4417031920495254ff566ee235234bfb 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -180,6 +180,7 @@ class DsInstance(service.Service):
self.dercert = None
self.idstart = None
self.idmax = None
+self.subject_base = None
if realm_name:
self.suffix = util.realm_to_suffix(self.realm_name)
self.__setup_sub_dict()
diff --git a/ipaserver/install/replication.py b/ipaserver/install/replication.py
index 21e6bcc4970f5d534df882f98327ace9119db983..756bb5595226d49e31edf5ce5afd12d26ac26758 100644
--- a/ipaserver/install/replication.py
+++ b/ipaserver/install/replication.py
@@ -625,7 +625,8 @@ class ReplicationManager:
# there is no other side to get a replica ID from
# So we generate one locally
replica_id = self._get_replica_id(self.conn, self.conn)
-self.basic_replication_setup(self.conn, replica_id)
+self.basic_replication_setup(self.conn, replica_id,
+ self.repl_man_dn, self.repl_man_passwd)
#now add a passync user allowed to access the AD server
self.add_passsync_user(self.conn, passsync_pw)
@@ -638,8 +639,9 @@ class ReplicationManager:
logging.info("Agreement is ready, starting replication . . .")
#Finally start replication
-return self.start_replication(self.conn, ad_conn,
- self.repl_man_dn, self.repl_man_passwd)
+ret = self.start_replication(ad_conn)
+if ret != 0:
+raise RuntimeError("Failed to start replication")
def convert_to_gssapi_replication(self, r_hostname, r_binddn, r_bindpw):
r_conn = ipaldap.IPAdmin(r_hostname, port=PORT, cacert=CACERT)
--
1.7.3.4
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Unable to start the krb5kdc
On Tue, 25 Jan 2011 12:04:25 -0500 James Roman wrote: > I noticed today that one of our FreeIPA 1.2.2 servers has stopped > issuing tickets. When I attempt to restart all the IPA services the > krb5kdc service failed to restart with the following error: > > krb5kdc: Unable to access Kerberos database - while initializing > database for realm DOMAIN.COM > > I don't see any issues with the local LDAP database, or the kdc > account in the LDAP database. I suspect the problem is with the > ticket granting ticket on the problem server, but am unsure how to go > about validating this assertion. I have not tried to restart the ipa > services on the working server for fera that it might stop working. Do you see errors in /var/log/krb5kdc.log ? 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] Unable to start the krb5kdc
On Tue, 25 Jan 2011 14:33:14 -0500 James Roman wrote: > On 01/25/2011 12:42 PM, Simo Sorce wrote: > > On Tue, 25 Jan 2011 12:04:25 -0500 > > James Roman wrote: > > > >> I noticed today that one of our FreeIPA 1.2.2 servers has stopped > >> issuing tickets. When I attempt to restart all the IPA services the > >> krb5kdc service failed to restart with the following error: > >> > >> krb5kdc: Unable to access Kerberos database - while initializing > >> database for realm DOMAIN.COM > >> > >> I don't see any issues with the local LDAP database, or the kdc > >> account in the LDAP database. I suspect the problem is with the > >> ticket granting ticket on the problem server, but am unsure how to > >> go about validating this assertion. I have not tried to restart > >> the ipa services on the working server for fera that it might stop > >> working. > > Do you see errors in /var/log/krb5kdc.log ? > > > > Simo. > > > The error above is the only one that repeats in the krb5kdc.log when > I attempt to restart the krb5kdc service. The actual error that is > shown in standard out is: > > Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm DOMAIN.COM > - see log file for details Ok can you check the dirsrv logs and see if the KDC is actually trying (and perhaps getting auth refused) at all ? /var/log/dirsrv/slapd-DOMAIN-COM/access should show your KDC attempts to access the LDAP server and bind as the uid=kdc. user. 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] Unable to start the krb5kdc
On Tue, 25 Jan 2011 15:58:35 -0500 James Roman wrote: > On 1/25/11 2:44 PM, Simo Sorce wrote: > > On Tue, 25 Jan 2011 14:33:14 -0500 > > James Roman wrote: > > > >> On 01/25/2011 12:42 PM, Simo Sorce wrote: > >>> On Tue, 25 Jan 2011 12:04:25 -0500 > >>> James Roman wrote: > >>> > >>>> I noticed today that one of our FreeIPA 1.2.2 servers has stopped > >>>> issuing tickets. When I attempt to restart all the IPA services > >>>> the krb5kdc service failed to restart with the following error: > >>>> > >>>> krb5kdc: Unable to access Kerberos database - while initializing > >>>> database for realm DOMAIN.COM > >>>> > >>>> I don't see any issues with the local LDAP database, or the kdc > >>>> account in the LDAP database. I suspect the problem is with the > >>>> ticket granting ticket on the problem server, but am unsure how > >>>> to go about validating this assertion. I have not tried to > >>>> restart the ipa services on the working server for fera that it > >>>> might stop working. > >>> Do you see errors in /var/log/krb5kdc.log ? > >>> > >>> Simo. > >>> > >> The error above is the only one that repeats in the krb5kdc.log > >> when I attempt to restart the krb5kdc service. The actual error > >> that is shown in standard out is: > >> > >> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm > >> DOMAIN.COM > >> - see log file for details > > Ok can you check the dirsrv logs and see if the KDC is actually > > trying (and perhaps getting auth refused) at all ? > > > > /var/log/dirsrv/slapd-DOMAIN-COM/access should show your KDC > > attempts to access the LDAP server and bind as the uid=kdc. > > user. > > > > Simo. > > > Looks like an authentication failure: > > [25/Jan/2011:15:11:29 -0500] conn=391 op=0 BIND > dn="uid=kdc,cn=sysaccounts,cn=etc,dc=domain,dc=com" method=128 > version=3 [25/Jan/2011:15:11:29 -0500] conn=391 op=0 RESULT err=49 > tag=97 nentries=0 etime=0 > [25/Jan/2011:15:11:29 -0500] conn=391 op=-1 fd=73 closed - B1 > > The ldappwd file on both systems look identical. I don't think that > the SSL certificate comes into the equation, but I have no way of > knowing whether it initiates TLS or not. No in ipa 1.2.x the kdc is configured to use ldap://127.0.0.1 with no auth. I wonder if your local DS is having problems. Can you change krb5.conf to point to the other server (maybe using ldaps:// so as to not expose the password in the clear) and see if the krb5kdc will start that way ? Don't use this in production, just as a test to identify where the problem lies. if it turns out it is the local DS that is having issues, then we can try to force sync it again. Ah btw, on what distribution version is this? what 389-ds base version are you using ? 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] admin password
On Thu, 2011-01-27 at 09:09 -0500, Uzor Ide wrote: > Hi all > > How do I make admin password not to expire immediately after changing > it? It is always set to expire even if you use kpasswd to change 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] Unable to start the krb5kdc
On Wed, 2011-01-26 at 13:59 -0500, James Roman wrote: > So it looks like the replication password issue was a red herring as > far as the kerberos is concerned. I issued the command > "ipa-replica-manage synch ipaserver1.domain.com" from the working ldap > replica and no longer get password expiration errors in the error > logs. However, I still can not get the krb5kdc process on ipaserver1 > to start when it uses the local (ldap://127.0.0.1/) LDAP database. If > I perform an LDAP search of the kdc account using the Directory > Manager account, both kdc entries are identical, so it does not seem > to be the password for the KDC account that is preventing the krb5kdc > service from starting. Could it be the service or host principals? > Should I init from ipaserver2 -> ipaserver1 (Note: ipaserver1 is the > winsync server)? > > ipaserver1: > FC 11 > ipa-server-1.2.2-2.fc11.i586 > > ipaserver2: > FC10 > ipa-server-1.2.2-1.fc10.i386 I am surprised you get back INVALID CREDENTIALS as an error when the KDC tries to log in using the data in ldappwd, given it works against the other server ... If you search with directory manager the accounts on both servers, do you get back an identical userPassword field ? 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] Unable to start the krb5kdc
On Thu, 27 Jan 2011 19:20:02 -0500 James Roman wrote: > On 1/27/11 12:58 PM, Simo Sorce wrote: > > On Wed, 2011-01-26 at 13:59 -0500, James Roman wrote: > >> So it looks like the replication password issue was a red herring > >> as far as the kerberos is concerned. I issued the command > >> "ipa-replica-manage synch ipaserver1.domain.com" from the working > >> ldap replica and no longer get password expiration errors in the > >> error logs. However, I still can not get the krb5kdc process on > >> ipaserver1 to start when it uses the local (ldap://127.0.0.1/) > >> LDAP database. If I perform an LDAP search of the kdc account > >> using the Directory Manager account, both kdc entries are > >> identical, so it does not seem to be the password for the KDC > >> account that is preventing the krb5kdc service from starting. > >> Could it be the service or host principals? Should I init from > >> ipaserver2 -> ipaserver1 (Note: ipaserver1 is the winsync server)? > >> > >> ipaserver1: > >> FC 11 > >> ipa-server-1.2.2-2.fc11.i586 > >> > >> ipaserver2: > >> FC10 > >> ipa-server-1.2.2-1.fc10.i386 > > I am surprised you get back INVALID CREDENTIALS as an error when > > the KDC tries to log in using the data in ldappwd, given it works > > against the other server ... > > > > If you search with directory manager the accounts on both servers, > > do you get back an identical userPassword field ? > > > > Simo. > > > Yes, when I check the passwords are also identical. Odd. Have you ever played with DS password policies by chance ? Can you search explicitly for the paswwordExpirationTime on both uid=kdc accounts and see if it set by chance ? You need to search explicitly for the attribute as it is not returned by default. 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] Unable to start the krb5kdc
On Fri, 28 Jan 2011 09:20:37 -0500 James Roman wrote: > OK. Now I feel like an idiot. I swear that was the first thing I > checked. It seems the password policy on this server was set at the > base, instead of cn=users. We have a script that reports on expiring > accounts in the cn=accounts branch, but not under cn=etc. I now know > what to fix. Thanks. Rirst of all. I am glad this was resolved, it looked puzzling indeed. I just want to note that we do not support using the DS password policy in ipa as we already have the kerberos pw policy, that's why the uid=kdc was not "protected" against it. In v2 we perfected the pw policies check so that the kerberos policies covers also binds done against DS directly. I also am adding a patch so that uid=kdc is protected in case DS policy is enabled nonetheless for whatever reason. 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] Unable to start the krb5kdc
On Fri, 28 Jan 2011 17:39:14 -0500 James Roman wrote: > On 01/28/2011 10:39 AM, Simo Sorce wrote: > > > > Rirst of all. > > I am glad this was resolved, it looked puzzling indeed. > > > > I just want to note that we do not support using the DS password > > policy in ipa as we already have the kerberos pw policy, that's why > > the uid=kdc was not "protected" against it. > > > > In v2 we perfected the pw policies check so that the kerberos > > policies covers also binds done against DS directly. > Just to clarify, in v2 Kerberos password policies also cover ldap > binds? Yes with have a bind pre/post op plugin that enforces the same account/password policies for ldap binds too. 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] IPA server certificate update and "Directory Manager" password
On Tue, 1 Feb 2011 12:38:50 -0500 Peter Doherty wrote: > If I want to start from scratch with the new Beta release, how would > I dump the entire LDAP/KRB database so that I could import it into a > new server? > The Docs mention doing regular backups, but they don't even tell how > to backup the data, whether to backups files (which ones?!) or to > dump the data into a file, and backup that. database dumps + filesystem backups > Can I convert from the 1.9 alpha to a 2.0beta freeipa instance? Not easy, and it depends on what you mean by convert. A simple rpm update will give you issues because we still made minor changes to the DIT and schema between the 1.9 alpha and the beta. If you have many keys in your kerberos database I can describe a procedure that *should* work to dump the keys and reload them in a new server where you manually/script migrate the users/host/services data by using the ipa user-add/host-add/srvice-add commands. 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] export entire ldap/kerberos/etc onto a new host
On Tue, 1 Feb 2011 22:30:50 -0500 Peter Doherty wrote: > > On Feb 1, 2011, at 15:04 , Dmitri Pal wrote: > > > > Also it is worth mentioning that we are planning to come up with > > Beta 2 later this week so may be it makes sense to wait couple days > > and move to the latest bits. > > Can I upgrade from Beta-1 to Beta-2, or are they incompatible? There are small incompatibilities, some new schema and some changes to the DIT. 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] export entire ldap/kerberos/etc onto a new host
On Wed, 2 Feb 2011 09:28:38 -0500 Peter Doherty wrote: > > On Feb 2, 2011, at 09:09 , Simo Sorce wrote: > > > On Tue, 1 Feb 2011 22:30:50 -0500 > > Peter Doherty wrote: > > > >> > >> On Feb 1, 2011, at 15:04 , Dmitri Pal wrote: > >>> > >>> Also it is worth mentioning that we are planning to come up with > >>> Beta 2 later this week so may be it makes sense to wait couple > >>> days and move to the latest bits. > >> > >> Can I upgrade from Beta-1 to Beta-2, or are they incompatible? > > > > There are small incompatibilities, some new schema and some changes > > to the DIT. > > > > So you can't upgrade from 1.2 to 1.9 and you can't go from 1.9 to 2.0 > and you can't go from 2.0 beta-1 to 2.0 beta-2? > > So why would I want to use a product like that? Upgrades will be possible within stable releases. Handling upgrades in development versions would cost too much development time w/o any real benefit as schema and DIT will be fixed in stone once 2.0 final will be released. Alpha and Beta release are not meant for production but only for testing environments. 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] FreeIPA future releases.
On Fri, 4 Feb 2011 15:00:46 -0600 "Hemminger, Corey Lee. [heco0...@stcloudstate.edu]" wrote: > I have 2 questions. First is a possible idea of when FreeIPA v2 will > go gold and have the final stable release? This will help me with my > lab and small data center planning. Also second is more of a > suggestion, and that you guys should look at incorporating DHCP into > IPA like you did DNS. Also for it to be able to dynamically update > the DNS with machines that connect to the network. I work inside but > separate from a college campus network and we have laptops coming and > going from our network and being a research lab we are always tearing > machines down and rebuilding them and renaming them. You should be able to configure named to accept DNS updates from your dhcp server adding configuration to allow a specific IP (that of the dhcp) to update any entry. However we will evaluate whether integrating DHCP is something we can do for a future release, or maybe something people are willing to contribute. 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] Freeipa Windows 7 client authentication
On Wed, 9 Feb 2011 16:13:39 +
Brett Maton wrote:
> Hi,
>
> I can't get a Windows 7 client to authenticate against Freeipa (ver
> 2.0.0.pre2) running on Fedora 14.
>
> Feb 09 16:03:22 krb5kdc[32355](info): AS_REQ (7 etypes {18 17 23 3 1
> 24 -135}) 192.168.0.2: NEEDED_PREAUTH: mat...@example.com for
> krbtgt/example@example.com, Additional pre-authentication
> required Feb 09 16:03:22 krb5kdc[32355](info): preauth (timestamp)
> verify failure: Decrypt integrity check failed Feb 09 16:03:22
> krb5kdc[32355](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135})
> 192.168.0.2: PREAUTH_FAILED: mat...@example.com for
> krbtgt/example@example.com, Decrypt integrity check failed Feb 09
> 16:03:23 krb5kdc[32355](info): preauth (timestamp) verify failure:
> Decrypt integrity check failed Feb 09 16:03:23 krb5kdc[32355](info):
> AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.0.2: PREAUTH_FAILED:
> mat...@example.com for krbtgt/example@example.com, Decrypt
> integrity check failed
>
> Any help with where to start looking or what might be wrong would be
> greatly appreciated.
Either the password is wrong or the time on your client is not within 5
min. of the time on the KDC.
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] Freeipa Windows 7 client authentication
On Wed, 9 Feb 2011 16:13:39 + Brett Maton wrote: > I can't get a Windows 7 client to authenticate against Freeipa (ver > 2.0.0.pre2) running on Fedora 14. Brett, can you tell me what krb5-server package do you have installed ? 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] limit access to a specific CN
On Tue, 15 Feb 2011 14:09:07 -0500 Peter Doherty wrote: > > On Feb 15, 2011, at 14:02 , Rob Crittenden wrote: > > > Peter Doherty wrote: > >> Hello, I'm running Fedora 14 and freeipa 1.2.2-6 > >> > >> > >> Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com) > >> and then create an account that can edit that cn as much as they > >> want, > >> but can't edit the other ones (ie: accounts, groups...)? > >> Any pointers to documentation would be useful. Unfortunately I'm > >> not 100% clear on my terminology, so google searches are leading > >> me a bit astray. > > > > What would you put into this container? > > > > 389-ds certainly supports doing this, depending on what exactly > > you want to do IPA may or may not support it. For example, we look > > for a type of entry only within a given container, so you can't put > > users into another location. > > > > rob > > The first thing I'm looking to do with it is have a web server that > has account information stored in LDAP, and to allow users to to > ldap authentication. The users logging into the web server would be > different from the posix groups that are managed by FreeIPA. I want > to replace htaccess and htpasswd files and use LDAP instead. > It seems like I could create a subsection in LDAP and set up apache > to bind and auth against that. But I also want a seperate ldap > admin account that can only edit this section, and not the rest of > the FreeIPA data. > Thanks. It is possible to do using LDAP tools and then setting an ACI on the container to give the user you want full control on that container. 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] 389 DS server closing connection after upgrade from Fedora 12 to 13
On Mon, 21 Feb 2011 02:07:36 +0100 "tomasz.napier...@allegro.pl" wrote: > Feb 20 23:47:19 Updated: 389-ds-base-1.2.7.5-1.fc13.x86_64 > > Any one have an idea what could be the reason? If I remember correctly, some people reported similar issues with 1.2.7 It doesn't affect everyone but afaik the lock-up bug has been fixed in the 1.2.8 alphas. You may want to try to upgrade 389ds with the version in updates-testing and see if that fixes this problem. 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] Announcing FreeIPA v2 Server Release Candidate 2 Release
On Wed, 2 Mar 2011 16:45:07 +1300 Steven Jones wrote: > > > I think it is a mismatch between what we've stored as the hostname > > and the hostname of the machine. > > > > Can you look at the output of these commands and see if the > > hostname is the same between them all? > > > > $ ldapsearch -x -s one -b > > cn=masters,cn=ipa,cn=etc,dc=ipa,dc=ac,dc=nz dn $ hostname > > $ cat /etc/sysconfig/network (there should be only one HOSTNAME) > > > > thanks > > > > rob > > > > So I un-installed and re-installed rc2, here is the output as > requested, > > === > > [root@fed14-64-ipam001 /]# kinit admin > Password for ad...@ipa.ac.nz: > [root@fed14-64-ipam001 /]# ldapsearch -x -s one -b > cn=masters,cn=ipa,cn=etc,dc=ac,dc=nz dn > # extended LDIF > # > # LDAPv3 > # base with scope oneLevel > # filter: (objectclass=*) > # requesting: dn > # > > # search result > search: 2 > result: 32 No such object What is the realm name you choose ? > # numResponses: 1 > [root@fed14-64-ipam001 /]# > > fed14-64-ipam001 > NETWORKING=yes > HOSTNAME=fed14-64-ipam001 > NTPSERVERARGS=iburst The server hostname must be fully qualified on an ipa server. 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] Time bug
On Fri, 4 Mar 2011 15:16:36 +1300 Steven Jones wrote: > Hi, > > Americans are funny ppl they put the date format as month then > day.the problem is in the real world, its day then month > > So I have registered 1 client and 2 ipa masters as of 4th march 2011 > NZST, but the IPA server's gui says I registered them a month in the > future, ie 3rd April 2011 GMT+12 NZSTvery neat... > > ;] > > So you need some sort of detection script/software to sort that I > suspect.or fix the display format in the gui...? > > Possibly this might not be helping with my issues as all my machines > think its NZST while the IPA master server's software might be > thinking they are telling it April? hence security certificates etc > go "boom"? No, it is just a display issue in the UI, internally all software uses unix timestamps and UTC. 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] Unable to authenticate a client user against IPA
On Tue, 8 Mar 2011 19:05:45 -0500 (EST) Stephen Gallagher wrote: > > > On Mar 8, 2011, at 5:45 PM, Steven Jones > wrote: > > > Keytab name: WRFILE:/etc/krb5.keytab > > KVNO Principal > > > > -- > > > > 8><- > >> > >> > >> > >> > > Looks like you have no host key in the keytab. That's the root of the > problem. Seems like IPA-client-install failed to populate it. Rob, do > you have any insight here? does /var/log/ipaclient-install.log show any error ? 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] Unable to authenticate a client user against IPA
- Original Message - > Steven Jones wrote: > > Ok, > > > > However I cant LDAP/Ipa authenticate stillon either > > client.. > > > > So what next? > > sssd handles logins, you can try turning up the log level on that > (though I suspect it wasn't the reboot that fixed this but restarting > sssd). If sssd was never used before then what was needed was a restart of the services using it (sshd, gdm), as nsswitch.conf is never re-read by glibc, you can't use the new users until those services are restarted after nsswitch.conf is modified. I think we also offer to restart the client after ipa-client-install exactly as a way to restart all services that may depend on picking up this change. That reboot is not necessary if you manually restart all services after that, but if you don't than you better do a reboot as we suggest. > As part of ipa-client-install sssd is restarted and tested via 'getent > passwd admin'. This should be visible in > /var/log/ipaclient-install.log. > Did this command succeed? Even if this succeed, authentication via gdm or ssh can still fail until the services are restarted. Just pointing out this fact as a help point for other users testing ipa-client-install in 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
Re: [Freeipa-users] Unable to authenticate a client user against IPA
- Original Message - > Fri Mar 11 12:47:41 2011) [sssd[be[ipa.ac.nz]]] > [sss_krb5_verify_keytab_ex] (0): Principal > [host/fed14-64-ipacl03.ipa.ac...@ipa.ac > .NZ] not found in keytab [default] > (Fri Mar 11 12:47:41 2011) [sssd[be[ipa.ac.nz]]] [setup_child] (0): > Could not verify keytab > (Fri Mar 11 12:47:41 2011) [sssd[be[ipa.ac.nz]]] [load_backend_module] > (0): Error (14) in module (ipa) initialization (sssm_ipa_id > _init)! > (Fri Mar 11 12:47:41 2011) [sssd[be[ipa.ac.nz]]] [be_process_init] > (0): fatal error initializing data providers > (Fri Mar 11 12:47:41 2011) [sssd[be[ipa.ac.nz]]] [main] (0): Could not > initialize backend [14] > (Fri Mar 11 12:47:42 2011) [sssd[be[ipa.ac.nz]]] > [sss_krb5_verify_keytab_ex] (0): Principal > [host/Fed14-64-ipacl03.ipa.ac.nz@IPA.A > C.NZ] not found in keytab [default] > (Fri Mar 11 12:47:42 2011) [sssd[be[ipa.ac.nz]]] [setup_child] (0): > Could not verify keytab > (Fri Mar 11 12:47:42 2011) [sssd[be[ipa.ac.nz]]] [load_backend_module] > (0): Error (14) in module (ipa) initialization (sssm_ipa_id > _init)! > (Fri Mar 11 12:47:42 2011) [sssd[be[ipa.ac.nz]]] [be_process_init] > (0): fatal error initializing data providers > (Fri Mar 11 12:47:42 2011) [sssd[be[ipa.ac.nz]]] [main] (0): Could not > initialize backend [14] > [root@Fed14-64-ipacl03 sssd]# > > > root@Fed14-64-ipacl03 sssd]# klist -k /etc/krb5.keytab > Keytab name: WRFILE:/etc/krb5.keytab > KVNO Principal > > -- > 1 host/fed14-64-ipacl03.ipa.ac...@ipa.ac.nz > 1 host/fed14-64-ipacl03.ipa.ac...@ipa.ac.nz > 1 host/fed14-64-ipacl03.ipa.ac...@ipa.ac.nz > 1 host/fed14-64-ipacl03.ipa.ac...@ipa.ac.nz > [root@Fed14-64-ipacl03 sssd]# > > ? > Caught Steven on IRC, this was a case of hostname being mixed case, which confuses kerberos libraries as they are case-sensitive and expect all lowercase names for hosts. This would not have been a problem if sssd just used the first key in the keytab instead of trying to guess the principal name in advance. (Yeah being stingy, no pressure Stephen :-) 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] Sync with AD error
On Fri, 11 Mar 2011 21:31:50 +0100 Sigbjørn Lie wrote: > > > On 03/11/2011 09:15 PM, Dmitri Pal wrote: > > On 03/11/2011 03:00 PM, Sigbjørn Lie wrote: > >> Hi, > >> > >> I just upgraded my FreeIPA @ F14 to 2.0.0.rc3, and attempted to > >> add a sync agreement with Active Directory. > > Did you upgrade in place or re-installed? > > The recent (a month ago or so) changes moved the location of the > > replication agreements. > > There were a lot of other changes in this area. > > We do not support smooth migration between beta and RCs that would > > have taken too much effort. > > Can you please try on a fresh install? > > > > Thank you > > Dmitri > > > >> Added CA certificate /root/testing-ca.cer to certificate database > >> for ipasrv01.ix.testing.com > >> ipa: INFO: AD Suffix is: DC=ad,DC=testing,DC=com > >> The user for the Windows PassSync service is > >> uid=passsync,cn=sysaccounts,cn=etc,dc=ix,dc=testing,dc=com > >> Windows PassSync entry exists, not resetting password > >> ipa: INFO: Added new sync agreement, waiting for it to become > >> ready . . . ipa: INFO: Replication Update in progress: FALSE: > >> status: 0 Replica acquired successfully: Incremental update > >> succeeded: start: 20110311195207Z: end: 20110311195207Z > >> ipa: INFO: Agreement is ready, starting replication . . . > >> ipa: INFO: Failed to create public entry for winsync replica > >> Starting replication, please wait until this has completed. > >> Update succeeded > >> Connected 'ipasrv01.ix.testing.com' to 'addc01.ad.testing.com' > >> > >> > >> Now I can't list the sync agreements. All I get is: > >> > >> # ipa-replica-manage list > >> unexpected error: * not found > >> > >> Any ideas? > >> > >> > >> Rgds, > >> Siggi > >> > >> _______ > >> Freeipa-users mailing list > >> Freeipa-users@redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > >> > > > > > Hi, > > I upgraded in place. I did the initial installation on the 12th of > February. I think I started out with the first RC. Do I still have to > reinstall? Have you run ipa-ldap-updater after the rpm upgrade ? 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] Delete AD replica failure
On Sun, 20 Mar 2011 18:28:12 +0100
Sigbjorn Lie wrote:
> Hi,
>
> I just did a fresh installation of FreeIPA 2 on a host called ipa1,
> created a replica on a second server called ipa2. I then created a
> winsync replica to an AD domain on the ipa1 host.
>
> I noticed that I forgot the --win-subtree option and decided to
> delete the replication agreement:
>
> # ipa-replica-manage -H ipa1.ix.nowhere.com del dc01.ad.nowhere.com
> Directory Manager password:
> Unable to delete replica dc01.ad.nowhere.com: {'desc': "Can't contact
> LDAP server"}
This is not the correct command to use.
> If I did a force a got a bit more output, where it complains about
> the ipa2 replica server not having a sync agreement with the dc01
> server.
>
> # ipa-replica-manage -v -f -H ipa1.ix.nowhere.com del
> dc01.ad.nowhere.com Directory Manager password:
> Unable to connect to replica dc01.ad.nowhere.com, forcing removal
> Forcing removal on 'dc01.ad.nowhere.com'
> 'ipa2.ix.nowhere.com' has no replication agreement for
> 'dc01.ad.nowhere.com'
>
>
> Is this intended behavior or a bug?
Intended, to remove the AD replication link you need to 'disconnect'
the AD server.
Use:
ipa-replica-manage disconnect dc01.ad.nowhere.com
> After re-creating the sync agreement with the win-subtree option, IPA
> synced with AD successfully.
Great,
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] ipa client install
On Wed, 23 Mar 2011 20:43:24 -0400 Rob Crittenden wrote: > Uzor Ide wrote: > > I have manually enrolled and configured the client. I am able to log > > into the client and access nfs4 shares. What I am wondering is if > > there are anything that the client would miss by joining this way. > > The client authenticate to the ipa-server through sssd. I would > > like to know if HBAC and centrally managed SUDO and other policy > > enforcements will fail to work because the manual enrolment. Note > > that host certificate was not generated because of the manual > > joining. > > I guess it means by how you manually joined but based on what you can > do I think you covered the major details. > > If you have a host service principal in /etc/krb5.keytab and a > correctly configured sssd then you are fine for HBAC and nss (users, > groups, etc). > > SUDO works through nss_ldap so you should be fine there as well. To avoid confusion (if possible :) sudo uses the nss_ldap config file, but not the nss_ldap code. So all you need to do is to read the sudo docs to find which file you need to touch. Of course because sudo doesn't go though sssd (yet) it will not work properly in offline mode, unfortunately. > ipa-client-install doesn't do anything too special, it just makes > sure the environment is sane and then sets up sssd.conf, krb5.conf, > fetches a host service principal and uses certmonger to get an SSL > server cert. This last step is done as a convenience, it otherwise > isn't used by IPA. But if you wanted to setup an HTTP server that > uses the same PKI as IPA you'd have a certificate and key available. > > cheers -- 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] NIS/local files to IPA migration
On Mon, 28 Mar 2011 15:43:18 +0200 (CEST) "Sigbjorn Lie" wrote: > On Mon, March 28, 2011 15:24, Dmitri Pal wrote: > > On 03/28/2011 09:01 AM, Sigbjorn Lie wrote: > > > >> On Mon, March 28, 2011 14:31, Dmitri Pal wrote: > >> > >>> On 03/27/2011 06:14 PM, Sigbjorn Lie wrote: > >>> > >>> > >>>> Hi, > >>>> > >>>> > >>>> > >>>> I have written some scripts for migration from NIS/local files > >>>> to IPA. They will import the passwd, group, netgroup, and hosts > >>>> maps. > >>>> > >>>> > >>>> > >>>> This is the first version, be aware of bugs. :) > >>>> > >>>> > >>>> > >>>> Please read the README file before using. > >>>> > >>>> > >>>> > >>>> You can download them from here if you are interested: > >>>> http://www.nixtra.com/ipa/NIS-TO-IPA-current.php > >>>> > >>>> > >>> Thank you for the contribution! > >>> I see that it is under GPL v2. Would you mind relicensing it > >>> under GPL v3? http://www.gnu.org/licenses/gpl-3.0.html > >>> > >>> > >>> > >>> Would you be interested in these scripts being incorporated into > >>> the project source? Rob, can you please take a look into this? > >>> Should we consider rewriting them in Python and incorporating > >>> into the main tool set or leave and use as is? > >>> > >>> > >>> > >> Sure I can relicense to GPL v3. All I care about is the scripts > >> staying open and free to use. :) > >> > >> > >> You can include as a part of IPA if you would like. I was planning > >> to re-write them all into perl, as my initial efforts to write > >> them in bash for maximum portability didn't work out, and the > >> netgroup and hosts import scripts ended up written in perl. > >> > >> I cannot help re-writing to python, I don't know the language. > >> > >> > > > > Ok, thank you! > > > > > > Can you elaborate a bit about the constraints you have regarding > > migration. As far as I understand you have users and groups with > > colliding gids and you have to resolve things manually to make > > things exactly as they were and IPA as is does not allow you to do > > so as it always creates a privite group with the same GID. > > > > I have a stupid question: what is the implication of actually not > > doing things exactly as they were but rather embracing the IPA > > model of the unified UID/GID namespace? Is the reason that there > > are some applications scattered in the enterprise that might have > > gids configured explicitly in the configuration files (like SUDO > > for example) and updating those would be a challenge or there is > > something else? > > > > That question is not stupid. However...:) > > Migrating group id's is possible, but quite a job. We just moved a > few users's uid's as they had been in the enterprise for very many > years, and had a dangerously low UID's. Searching trough the file > servers for files belonging to these few users using a "find -exec > chown ..." took 3 days. Migrating GID's would also take a very long > time. > > Secondly, any files restored from backup would have the wrong > uid/gid. Several of our clients have a rentention time of 10 years > for backups. That's quite some time to keep a mapping table over > new/old uids/gids. > > Third, we would need to map our applications to see if any of them > store or use the GID. > > As you can see, migrating to IPA just became a much more time > consuming and higher risk project than it could be. > > Is there a reason for why the approach with a private group per user > is forcibly chosen? As a default it gives us the maximum compatibility with other directory services (like AD). Plus when we did freeipa v1 we got a lot of push back when we choose a single group (ipausers) to be the primary group due to traditional umask use for users. So we decided to make it a default and let admins that really do not want it to remove the groups. I guess we could add a switch somewhere to turn off UPG groups creation completely, if you think that is something really important you may want to open an RFE, although I am not sure when we will have cycles to get to implement such a switch for the moment. 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] Questions from Steven Jones
On Tue, 2011-05-03 at 08:46 -0400, Dmitri Pal wrote: > I am posting Steven's questions as they have been sent to the wrong list > and were on hold. > > > > Hi > > Seem to be having issues postinganyway > > I notice that free-ipa really wants to work best as its own dns > etcproblem is with AD running integrated DNS there is a clashSo > Im wondering with say a domain of ipa.ac.nz whether it would be a good > idea or sensible and worthwhile to run ipa as a dns stub say unix.ipa.ac.nz? > > Would this cause any issues with anything? say passwd syncing with AD > under ipa.ac.nz (or actually its staff.ipa.ac.nz) > > >From reading the docs this looks like it might be a good idea, not sure... > > Are there any good high design and architecture docs I should read? to > answer such Qs? Having your own subdomain (or multiple subdomains) for IPA is certainly a good idea. This is not much due to our DNS integration, you can definitely handle DNS on your own, but has more to do with kerberos libraries and the way realm -> domain mapping is done in some cases. So if you organize your naming architecture to have IPA.EXAMPLE.COM -> ipa.example.com then you get the best interoperability matrix between all components. That doesn't mean other combinations won't work, but you will have to understand the details of how Keberos and DNS interrelate and how to change client configuration if you choose different strategies. Password syncing will have no problems related to DNS names, except, perhaps for the need to change your SSL certificate (as X509 certs for SSL embed the hostname of the server). 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] extending FreeIPA
On Wed, 2011-05-04 at 17:41 -0700, Stephen Ingram wrote: > I currently maintain a directory with MTA configuration data in it > (among other items). I'm wondering what is the best way to add to the > FreeIPA schema without stepping on current and future schema additions > that might conflict with what I add. I know at one time you were > expecting to add information for Postfix and other common server > programs. Was this schema ever prepared and agreed upon, or is it best > to use some special branch to put this all under? Ok it seem we are confusing 2 things here, on one side schema extensions (new attributes and objectclasses) and on the other side DIT structure (subtrees within the tree where to put your information). If you use standard schema or schema you made yourself after you got assigned a base OID there should be no issue at all. if you do your own schema please be careful in trying to use a prefix for attribute and objectclass names so that you do not risk future name conflicts). For the DIT part it really depends on what you need to do. If you just need to add attributes to users then you have no other option but to attach them to the users and that's fine it shouldn't cause any issue. If you need to add entirely new objects I can suggest to create a cn=custom container as a top level subtree (ie at the same level of cn=accounts and cn=etc, ... And within it do what you need to do. This way it will not conflict with anything we may add in future. > Also, although I read Adam Young's blog article about how to extend > the WebUI, I'm having difficulty adding attributes within the existing > structure. For example, on the user page, is there a prescribed way of > adding say, the mailAlternateAddress attribute such that it shows as a > field in the WebUI? I will let Adma reply to this one. HTH, 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] FreeIPA for Linux desktop deployment
On Thu, 2011-05-12 at 22:25 +0200, Sigbjorn Lie wrote: > You could also extend the High Availability configuration I mentioned > earlier with 1 high-available IP per IPA host, and serve them in a > round robin DNS. This would distribute the load of the LDAP server in > IPA, and provide high availability in case of a IPA server becoming > unavailable. Not as easy. With kerberos names have to be matched by keytabs. So if you use an alias you also have to create a keytab for that alias and distribute it on all machines (at the very least). Then you have to hope all server software is able to cope with using the key that matches the current authentication attempt (I know for a fact many services do not cope yet, and I have opened bugs for some). SSSD does automatically reconnect to another of the available IPA servers btw, so another plus for SSSD :) That said we have configuration instructions for other platforms, I am sure the community can hack-up scripts to use them if instructions are not enough. We can also host them if someone wants to contribute. 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] RHEL client to IPA
On Fri, 2011-05-13 at 11:11 +0200, Jakub Hrozek wrote: > On 05/13/2011 06:00 AM, Steven Jones wrote: > > [root@vuwunicoipamt01 etc]# ipa-getkeytab -k /tmp/vuwnicologint2.keytab -p > > host/vuwunicologint2.unix.vuw.ac.nz -s vuwunicoipamt01.unix.vuw.ac.nz -p > > admin > > The second -p overrides the first. And also probably changed the "admin" password to rubbish. 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] IPA Startup issues
On Sat, 2011-05-14 at 16:46 +0200, Sigbjorn Lie wrote: > I've noticed that if the machine running IPA is very busy at startup, > the IPA services will not be online when the machine is started. > > I noticed this is as my test virtualization host has had it's power cord > knocked out a few times. When I restart the host machine, all the > virtual machines is started at the same time, causing (a lot) higher > than normal latency for each virtual machine. > > This causes the IPA daemons to start, while during the startup one or > several IPA daemons fails due to dependencies of other daemons which is > not started yet, and all the IPA daemons is stopped as not all the IPA > daemons started successfully. I've noticed that the default behavior of > the ipactl command is to shut down all the IPA daemons, if any of the > IPA daemons should fail during startup. > > This can be seen in the logs of the individual services, as some is > started successfully, just to receive a shutdown signal shortly after. > It seem to be the pki-ca which shut down my IPA services this morning. > > When rebooting the virtual machine running the IPA daemons during normal > load of the host machine, all the IPA daemons start successfully. > Logging on to the IPA server and manually starting the IPA daemons after > the load of the host machine has decreased also works. > > I suggest changing the startup scripts to allow (a lot) longer startup > times for the IPA daemons prior to failing them. At the moment we just run service start and wait until it is done. If the pki-cad service timeouts and returns an error I think we need to open a bug against the dogtag component as that is the cause. Can you open a bug in the freeipa trac with logs showing that service is responsible for the failure ? 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] RHEL client to IPA
On Wed, 2011-05-18 at 03:18 +, Steven Jones wrote: > Im getting, > > "SASL bind failed!" As I said earlier this is happening because you changed the admin password with a random secret when you passed -p admin in the previous attempt. 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] RHEL client to IPA
On Wed, 2011-05-18 at 20:30 +, Steven Jones wrote: > Which is why I asked rob how to reset it which I didso its not > that?..at least it makes no obvious sense that it is? Once you reset the password as Rob told you all is fine again. 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] IPA server as a DNS server and design things
On Wed, 2011-05-18 at 23:07 +, Steven Jones wrote: > Qs, > > 1) We have a single master only for freeipa 2.0? so from what I can > read the replicas are passive? ie do they answer LDAP queries and also > DNS queries if DNS is integrated? but simply dont have a gui? or are > they totally inert? Im thinking of this as we really want 2 active > DNS servers minimum... We do not enable the DNS on replicas by default, it is an admin choice on which replicas they want to enable the DNS service. When you install the replica you can pass the --setup-dns flag. If you forgot to do so or if you later change idea and want to install the DNS piece you can simply run ipa-dns-install on the replica you want to have another DNS available. > 2) We discussed its better to have DNS as a stub domain off the main > domain.so Linux servers will be unix.vuw.ac.nz.should I do the > same for the reverse lookup? That depends on your network topology. At the moment we do create a reverse zone for you by default, but you can use it, disable it, or just remove it if you have reverse lookups handled elsewhere. In future though we plan to improve the DNS plugin so that it will automatically update also the reverse zone (if managed by IPA) on clients dynamic DNS updates. > Should I cleave off part of the class B? say 2 x 24s? problem then > becomes what do I do with mixed environments where I have windows web > front ends and linux db backends..or user areas where I cant do > that... It is not necessary, although I would recommend that you properly set the ptr records at least for your servers in the DNS that is managing your reverse zones. 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] help! IPA server she explode!
On Thu, 2011-05-19 at 01:41 +, Steven Jones wrote: > I have an internal ajax error! > > :( > > the logs say, Ping me later on IRC, I'd like you to run some commands, and it will be easier done interactively. Simo. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Clients are reading AD info inconsistently
On Wed, 2015-03-25 at 14:46 +, Guertin, David S. wrote: > Follow-up: today I tried clearing the sssd cache and restarting sssd on all > three clients, and all three lost their AD users: > > # rm -f /var/lib/sss/db/* > # service sssd restart > Stopping sssd: [ OK ] > Starting sssd: [ OK ] > # id 'MIDD\juser' > id: MIDD\juser: No such user > > David Guertin > This is normal, users are "loaded in" when they actually try to Log In. 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
Re: [Freeipa-users] Is systemd really a requirement for freeipa 4.x?
On Thu, 2015-03-26 at 13:23 +0100, Jan Pazdziora wrote: > On Thu, Mar 26, 2015 at 10:49:22AM +0100, Andrew Holway wrote: > > > > From an SELinux standpoint systemd is far superior to initd as it allows > > far more graceful domain transitions. > > Have you got a link which would demonstrate how systemd helps > with domain transitions? Hi everyone, before answering to the technical question I would like to ask that people refrain from comments on how good/bad systemd is, it is an inflammatory topic and people has really discussed it to no end all over the internet. I do not think we need to make camps here. Now on the SELinux thing, the init system (any init system) can transition easily to any domain it wants as it is the first process and it is explicitly given that permission by policy. The way systemd works when you run a unit file is that systemctl communicates to the init system commanding it to styart a specific unit file, then the init system does it setting up the appropriate SELinux context for the process. This is always consistent as calling systemctl is the only way to run a unit file. With the old sysV system (on Fedora/RHEL), instead the admin (root usually) had at least 2 ways of starting an init script. 1) use the service command 2) run the script directly Now if (1) was used then the service command could do a transition to the initd_t domain first and then be allowed to transition the script it would launch to the appropriate domain (just like init would do at boot). However if the admin directly executed the script instead of using the service command then this would not happen because there are no transition rules when root runs stuff directly. Root happens to have the unconfined_t role and so whatever it executes directly, normally, will inherit the same, which means unfettered access to most of the system. In turn this means the program may create files which also also marked unconfined_t (or other label not normally available to the program). Upon reboot (or proper restart via service file) the program would go back to start with the correct policy and find itself with no access to those files due to mismatching label (or behave differently due to different access to config files and the like). This was often the cause of hate by admins that do not understand the mechanics and nuances involved in using SELinux. HTH, 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
