Have you tried logging in and out of both your WordPress and bbPress installations and accessing both admin panels? I mean each combination each way.
- Log into WordPress; Check admin panel access and cookies; Log out of WordPress
- Log into bbPress; Check admin panel access and cookies; Log out of bbPress
- Log into WordPress; Check admin panel access and cookies; Log out of bbPress
- Log into bbPress; Check admin panel access and cookies; Log out of WordPress
That is where the problem lies, and I have been running the most updated trunks of both bbPress and WordPress the entire time. 
Short term, I was able to make this work by modifying 1 core WordPress file. This only allows for integration of the theme, but still does not allow access to the bbPress admin panel without changing the bb-config.php file back to original.
It’s essentially a quick fix to get the theme working with all capabilities playing nicely.
Basically I’m hard-coding the capability check from bbPress into WordPress. There should be a filter for this, but I’m not sure how to hook into it correctly without a mod or plug-in on the WordPress side.
~My fix is in no way a permanent solution. Auto-updating your WordPress installation will overwrite this fix.~
In FILE wp-includes/capabilities.php:
In the meta_map_cap function:
Around Line 906:
AFTER break;
BEFORE default
INSERT:
/*
*/
case 'write_post':
$caps[] = 'write_posts';
break;
case 'edit_post':
// edit_posts, edit_others_posts, edit_deleted, edit_closed, ignore_edit_lock
if ( !$bb_post = bb_get_post( $args[0] ) ) {
$caps[] = 'magically_provide_data_given_bad_input';
return $caps;
}
if ( $user_id == $bb_post->poster_id )
$caps[] = 'edit_posts';
else
$caps[] = 'edit_others_posts';
if ( $bb_post->post_status == '1' )
$caps[] = 'edit_deleted';
if ( !topic_is_open( $bb_post->topic_id ) )
$caps[] = 'edit_closed';
$post_time = bb_gmtstrtotime( $bb_post->post_time );
$curr_time = time() + 1;
$edit_lock = bb_get_option( 'edit_lock' );
if ( $edit_lock >= 0 && $curr_time - $post_time > $edit_lock * 60 )
$caps[] = 'ignore_edit_lock';
break;
case 'delete_post' :
// edit_deleted, delete_posts
if ( !$bb_post = bb_get_post( $args[0] ) ) {
$caps[] = 'magically_provide_data_given_bad_input';
return $caps;
}
if ( 0 != $bb_post->post_status )
$caps[] = 'edit_deleted';
// NO BREAK
case 'manage_posts' : // back compat
$caps[] = 'delete_posts';
break;
case 'write_topic':
$caps[] = 'write_topics';
break;
case 'edit_topic':
// edit_closed, edit_deleted, edit_topics, edit_others_topics
if ( !$topic = get_topic( $args[0] ) ) {
$caps[] = 'magically_provide_data_given_bad_input';
return $caps;
}
if ( !topic_is_open( $args[0]) )
$caps[] = 'edit_closed';
if ( '1' == $topic->topic_status )
$caps[] = 'edit_deleted';
if ( $user_id == $topic->topic_poster )
$caps[] = 'edit_topics';
else
$caps[] = 'edit_others_topics';
break;
case 'move_topic' :
$caps[] = 'move_topics';
break;
case 'stick_topic' :
$caps[] = 'stick_topics';
break;
case 'close_topic' :
$caps[] = 'close_topics';
break;
case 'delete_topic' :
$caps[] = 'delete_topics';
add_filter( 'get_topic_where', 'no_where', 9999 );
if ( !$topic = get_topic( $args[0] ) ) {
$caps[] = 'magically_provide_data_given_bad_input';
return $caps;
}
if ( 0 != $topic->topic_status )
$caps[] = 'edit_deleted';
remove_filter( 'get_topic_where', 'no_where', 9999 );
break;
case 'manage_topics' :
// back compat
$caps[] = 'move_topics';
$caps[] = 'stick_topics';
$caps[] = 'close_topics';
$caps[] = 'delete_topics';
break;
case 'add_tag_to':
// edit_closed, edit_deleted, edit_tags;
if ( !$topic = get_topic( $args[0] ) ) {
$caps[] = 'magically_provide_data_given_bad_input';
return $caps;
}
if ( !topic_is_open( $topic->topic_id ) )
$caps[] = 'edit_closed';
if ( '1' == $topic->topic_status )
$caps[] = 'edit_deleted';
$caps[] = 'edit_tags';
break;
case 'edit_tag_by_on':
// edit_closed, edit_deleted, edit_tags, edit_others_tags
if ( !$topic = get_topic( $args[1] ) ) {
$caps[] = 'magically_provide_data_given_bad_input';
return $caps;
}
if ( !topic_is_open( $topic->topic_id ) )
$caps[] = 'edit_closed';
if ( '1' == $topic->topic_status )
$caps[] = 'edit_deleted';
if ( $user_id == $args[0] )
$caps[] = 'edit_tags';
else
$caps[] = 'edit_others_tags';
break;
case 'edit_user':
// edit_profile, edit_users;
if ( $user_id == $args[0] )
$caps[] = 'edit_profile';
else
$caps[] = 'edit_users';
break;
case 'edit_favorites_of':
// edit_favorites, edit_others_favorites;
if ( $user_id == $args[0] )
$caps[] = 'edit_favorites';
else
$caps[] = 'edit_others_favorites';
break;
case 'delete_forum':
$caps[] = 'delete_forums';
break;
case 'change_user_password':
// change_password, edit_users
$caps[] = 'change_password';
if ( $user_id != $args[0] )
$caps[] = 'edit_users';
break;
/*
*/
Firstly, have you checked to make sure that your site paths are correct in both bbPress and WordPress? Since you shifted directories, the paths to those new directories need to be adjusted in the database.
Secondly, are there normal user tables to go along with those weird empty ones? Part of the integration process is telling bbPress which tables to find your users in. Is it possible that you added an extra “_” on accident, and bbPress created those tables while it was looking for the real ones?
We’re all experiencing the same issue.
Integration appears to be a little broken still.
If you need to use the WP functions in your bbPress, that will break it further by not allowing you to access your bbPress admin panel at all.
The problem looks like the bb_map_meta_cap filter is ignored when the WordPress functions are loaded in place of the bbPress ones.
Some users have been able to resolve this by using a .htaccess file to redirect to the bbPress login and register page whenever an attempt to register or login is made through WordPress. That is the best fix at the moment if you do not require access to the WP functions.
If you do require that access, then you will need to wait until a fix comes out for the issue I mentioned above. That’s where I am. 
It seems like there are several issues here, and I’m not sure which is really the issue or which is a bug…
Firstly, when integrated, bbPress wants to use the WordPress classes and functions where possible. Namely, the problem with capabilities lies currently with the difference in the WP_User->has_cap function.
On the WordPress side of it, it is missing the global $wp_roles; and the corresponding check of those roles against the current capability to check.
$caps = call_user_func_array( array(&$wp_roles, 'map_meta_cap'), $args );
So I’m not sure if this is just a case of bbPress not keeping up with the WordPress user/role classes, or if this is WordPress not properly carrying over bbPress capabilities.
Ugh…
I noticed this happening here and over at the WordPress.org forums, so there may have been some kind of a delay.
Looks good enough to me, although I haven’t checked the source to see exactly how you did it.
As of right now there isn’t a turn key solution. Im doing my best to see where the inclusion is going wrong but haven’t had much time the past few days.
What breaks it is the inclusion of the wordpress functions in the bb-config.php file. If you delete that code and visit the admin, it will work just fine.
Curious if you’ve tried the steps in my wp2.7 topic? It should essentially be the same as with 2.6.3 and everything works pretty well other than the wp header integration.
I never understand how responses like that work.
You make it sound like somehow you’ve been inconvenienced by us or by bbPress…
Looks to me like you failed to upload all of the files correctly.
@lorenzo: I’m not exactly sure if there is a modification to do that or not. It seems like it would be an easy enough process with a plug-in of some kind, but that isn’t the point of integration so unfortunately I have little experience with it.
@lorenzo: Let me ask a question to clarify. If I understand correctly, it sounds like you want to import your blog posts from WordPress and make them topic posts in bbPress?
@everyone: I am dedicating this evening to trying to work out where the process is failing. Right now, if you do NOT need to use ANY of the WordPress functions in your bbPress theme, the integration works perfectly. Logging in and out of either/or works perfectly with wp2.7 and bbp1.0a2. If you skip step 5 in my above process, there are no operational issues, only theme integration issues by not being able to use the WordPress functions.
That is why…
2.6x and .9 series won’t integrate or play nice together…
You could either go back to the 2.5 series of WordPress, or move up to the 1.0 beta version of bbPress…
Which versions of bbPress and WordPress are you using?
I’ve logged into both sides with a test account and still run into this problem. It seems that integrating with WordPress interferes with some capabilities. Like, when viewing a topic logged in as Key Master, I can see the IP addresses of people that post, and I have the link to add that topic to my favorites, but I cannot post a reply, I cannot edit the tags, and I cannot see any other admin functions; all of their capabilities return no value.
I haven’t given up yet! hah!
It looks like this has been addressed in the trac, but has yet to be repaired. So there is a ticket open for it, it’s on the radar, but still only a blip.
Depending on what version of phpMyAdmin you’re host is running, I find this ability currently under…
“Operations > Table Options > auto_increment”
There you can change that value back down to what it should be and cross your fingers! 
This does appear indeed to be an integration issue. When I remove the inclusion of the wp-blog-header.php in the bb-config.php, everything comes back just fine and I am able to edit/reorder/delete forums.
This seems to be the same issue causing most of my grief, somehow my capabilities and roles are totally out of alignment, or rather they may have never really been in total alignment in the first place.
Screen readers and modified browsers might love lists, but they also love properly coded tables, of which most people really seem to do.
Google “everything you know about css is wrong” and check out how to style lists and div’s as tables, it’s an interesting read also. I don’t agree with it, but it is interesting.
The idea of a DIV is not to nest them, but to use them to DIVIDE content. The idea of a table is to compare data in a relational way. I think if you were going to use lists for forums, you would HAVE TO use DL’s and use dt’s for the headers at the very least, to provide a definition to the content being displayed.
I mean, I see how the argument goes both ways. (Off topic: If you’re really into accessibility, check out my WordPress section 508 theme at http://www.wp508.com? It’s not completely full of content yet, seems I have about 5 half finished projects right now ugh.)
Wow…
It looks darn near perfect…
If your concern is catering to screen readers, then you know that phpBB is hardly the place to start, as reading the screen outloud to yourself makes no sense at all. Imagine if you couldn’t see what you were listening to, it would be impossible. That’s why (properly coded) tables for forums make sense. 
I noticed the topic view was buggered, didn’t want to load and show anything, so I assume that’s under construction… But, that’s pretty super awesome…
Well, you’d have to go poking around with phpMyAdmin, and change the users table and the usermeta table to match. This will prove difficult because the information is serialized in such a way as to make it difficult to read with the naked eye.
Will it cause a problem? In my OCD opinion, anything that isn’t meant to be that way can pose a problem later. How many users are affected by this issue? Can you delete them, reset the last ID in that table using phpMyAdmin, and ask them to re-register?
Hmm…
There should be a user-sync tool that does this without asking people to login twice, since the idea is to fully integrate them together seamlessly.
