Here, too. My understanding (I'm not a network person) is that if our
servers are all universally accessible via HTTPS from outside our
network, that we're pretty much stuck with NTLM. Does that mean no RSS
features for us?

Just wanted to ping again and see if anyone in the group had any
thoughts.

I'd like to second that! Also, some clarification would be great.

Is it the feeds that don't work sans Kerberos, or just the RSS reader
web part? If the latter, is it just a matter of finding/writing a web
part that can handle RSS sans Kerberos?

Also, at least out of the box, if we're installing MOSS using NTLM (as
our servers will be outside our firewall and accessed from the internet
rather than the LAN) are we just out of luck in terms of using RSS
within and between MOSS sites?

RSS works fine on NTLM between sites within a site collection. What it
can't do using NTLM is cross a Site Collection boundary. That's because
to do that requires the RSS webpart to delegate authentication. NTLM
doesn't do delegation. Kerberos does. That's why it will work with
Kerberos and not NTLM.

It doesn't even work for me within a site collection.

It may be a conscious design decision, but for all practical purposes for me
and my users it's just plain broken. I can't aggregate blogs within my own
intranet and my users can't use feed readers on things like their google
homepage.

And Kerberos is right out for us since the majority of our users aren't on
the local network. We're distributed throughout the state with our employees
"embedded" in other company's offices at their city level. The whole point
of sharepoint is to give our geographically distributed users an online
space to communicate.

I'm pretty pissed about this, honestly.

If your blogs are located on the user's MySite(which is the normal place
for them) then they aren't within a site collection. Each mysite is its
own site collection. And a Google home page is outside of SharePoint
entirely. So I'm not sure what you mean about it not working within a
site collection.

Also, the RSS webpart is an RSS viewer not an aggregator. It isn't
supposed to Aggregate RSS feeds.

This doesn't represent an issue with the way Microsoft has implemented
RSS (although I do wish the webpart was an aggregator and not just a
viewer). It's a limitation of RSS in general. Most RSS feeds are
designed to distribute information that is available anonymously. If
you setup SharePoint for anonymous access the RSS viewer will work as
well. You can aggregate RSS feeds from SharePoint if you get one of the
few RSS aggregators on the market that do authenticated RSS feeds. But
there aren't many of them.

The test I did was to create a blog site in the main portal site collection
then try to put the RSS Reader web part on the home page of the portal site
collection.

When you say the main portal site collection I suspect you mean the
Sites Directory. This is normally on the Sites Managed Path, which
means that things added here are normally in a different site collection
from the home page of the portal.

Nope, just from the portal front page I created a new site with the blog
site template. It's just a subsite at http://myportal/blog. Then on the
portal homepage I edit and add the rss  Viewer web part, point it at the new
blog site's rss feed and get the error about authenticated feeds.

I also tried it just inside a WSS site, creating a blog subsite in a team
site and then trying to put an RSS Viewer on the team site front page. Still
the authenticated feeds error.

The reason I mentioned Google home page was just an example of a common rss
reader (reader, not aggregator). I understand that it can't authenticate and
why. But my point is that if the rss  Reader in Sharepoint is effectively
broken without Kerberos, and popular third party rss readers can't access
the feeds either (for the obvious authentication reasons you mention which
I'm perfectly aware of), then RSS on my intranet portal is effectively
broken. I can't read the RSS on my portal or off. And I haven't found a
third party RSS Reader that works with authenticated sharepoint feeds.

So in order of preference, I need:

1. An RSS Reader in Sharepoint that works with an rss feed in any NTLM
authenticated environment.
2. An RSS Reader in Sharepoint that works within a SSP group of web apps in
an NTLM authenticated environment.
3. An RSS Reader in Sharepoint that works within a site collection in an
NTLM authenticated environment.
4. The ability to set anonymous authentication on rss feeds in sharepoint.
5. A beer.

Oh, and has anyone figured out how to put an RSS feed on just a category in
a blog? The blogs our partner institution companies are doing using either
dotnetnuke or coldfusion are doing this.

> It doesn't even work for me within a site collection.

I've had that same problem on our test install. Haven't gotten to play a
lot with it yet, though. Are there specific things I should be poking to
see why they aren't working? I can easily pull in any NON MOSS feed just
fine via the feedreader web part. Any MOSS feed, though, just gives me
the authentication error...even from within the same collection.

So, in terms of it only working within a site collection, does that mean
I couldn't sub to feeds and read them in another reader like Outlook?

> I'm pretty pissed about this, honestly.

I'm finding a lot of the feature in MOSS really only exist in name only.
We quickly realized the Wiki was underpowered to the point of being
rather useless, for instance.

Not that I like giving MS any freebies, but it is a relatively new
product. Maybe a hotfix or two will come along soon and remedy a few of
these issues.

I created the site collection's application with anonymous
authentication, and the top site collection doesn't have anonymous
enabled, but the subsites (blogs) are anonymous.

Of course that won't work if you want to make sure the blogs are
authenticated.

I have done pretty much the same thing - I used a doc library on the same
site - and have been getting the same behavior. kerberos  or no kerberos - I
get the authenticated feed error. I didn't spend a whole lot of time
troubleshooting it because its not a high priority - but it is annoying.

This is the defacto standard document to help you with Kerberos
configuration.

I've been going through this, like almost everyone else, and it's a
complete PITA to work with until you get it up and running.

Take a look at this:

blogs.msdn.com/.../configuring-kerbero
s-for-sharepoint-2007-part-1-base-configuration-for-sharepoint.aspx

Also, if you have multiple sites with Firewalls and IPS systems
scrubbing your traffic... then you need to make sure that Port 88 is
open to the MOSS server(s).

I just, today, figured out that the 3Com Tipping Point that we use here
was "scrubbing" out Kerberos tickets between out two sites. ...and it
did not generate an event ID to tell us!! So once you get it working at
one location, it should just work everywhere else. If not, you've got a
network issue.

Thanks all the the insight.

I had one more query. If the servers are configured with Kerberos,
and you are allowing users to connect to it in extranet environment -
will the setup work. Or do we need to go with NTLM as the external
users are not logged in the domain.

I'm pretty sure you'd end up with HTTPS and plain passwords if it's
external...

Can NTLM be used on the Internet?

That's my question too, as I'm not a networking person.

If the servers are HTTPS, my understanding is that you HAVE to use NTLM.

However, between the Front-end servers and your DB, can that be
Kerberos? And, if so, is that a way to get RSS working?

My understanding is "no". Whether RSS works or not with NTLM is not a
function of whether your database can read the data - clearly, it can,
or your SharePoint install would be quite broken. The problem has to
do with site-level permissions: just because, for instance, I have
access to:

https://blah/humanresources/

Does not mean I have access to:

https://blah/humanresources/blog/

The only way that SharePoint has to figure out whether the
authenticated user has access is for the authenticated user to pass
those credentials to the server, which then checks that information
against the list of people in the database that have access that
resource. NTLM is incapable of passing those credentials properly
(and this thread points that out) - Kerberos can, however, pass those
credentials.

let me clarify that, since I'm not sure what I just said was
quite what I meant. It doesn't matter what goes on between front-end
and back-end servers. The problem resides at the client/server level
and has nothing to do with server-to-server communication within the
server farm.

In summary, is it safe to say the following?:

- If your front end servers are sitting outside your LAN (outside your
Firewall) you have to use NTLM authentication.
- If you use NTLM authentication, you cannot use RSS feeds within MOSS

Even if we had Kerberos running and we only accessed our sites
internally, I'm still struggling to see what the perceived use of MOSS's
RSS implementation was if they are solely limited to reading from within
their own site collection. I suppose it's useful to 'bubble up' content
to a home page, but beyond that it seems like a feature that wasn't
fully thought out, perhaps?

I don't know for sure, but my suspicion is:

RSS feeds from one location to another in the MOSS 2007 server only support
Kerberos in order to ensure proper security. Not only should a user not be able
to see RSS feed content that they don't have rights to, but with the number of
RSS hacks and exploits that are out there, Kerberos adds another layer of armor
to your MOSS installation.

I've read that in the beta version you didn't have this issue. ...and right
around the time that MOSS was being released, we were seeing RSS feed related
attacks. I'm fairly confident that Kerberos based authentication to a feed
limits potential for exploits significantly.

Any thoughts on why Microsoft would recommend "Most of the
time, you should choose NTLM authentication" in the following article

http://support.microsoft.com/kb/832769

I would guess ease of integration with Active Directory, but don't
take my word for it.

Probably because the requirements for getting Kerberos working are too
convoluted for most installs, while NTLM is significantly easier and
generally considered "good enough" by most places.