Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Missing Tables WebUser and WebUserSiteAccess

7 views
Skip to first unread message

SK

unread,
Jun 30, 2009, 4:41:01 AM6/30/09
to
Hello All..
We are migrating from Axapta 3.0 to Ax 2009. In Axapta 3.0 we are using the
tables WebUser and WebUserSiteAccess to register the Web Users. In Ax 2009
the tables WebUser and WebUserSiteAccess no longer exist and the registration
code from Axapta 3.0 will no longer work in AX 2009. Can anybody give me an
advise which tables (Framework or whatever) we have to use to register Web
Users in AX 2009?

Thank you in advance....

Greetings...

SK

Bill Thompson

unread,
Jul 10, 2009, 11:41:13 AM7/10/09
to
Hello,
AX 3.0 EP compared to AX 2009 is quite different. The Enterprise Portal
site is now housed in Sharepoint (WSS 3.0 or MOSS). We now use Active
Directory for User Authentication as well.

I am going to paste in part of chapter 3 of the EP 2009 Development training
manual below which may help:

Enterprise Portal security uses a combination of features from:
• Microsoft Active Directory
• Windows SharePoint Services or Office SharePoint Server users and
groups
• Microsoft Dynamics AX access control

The authentication and granting access to Enterprise Portal process begins
when
a user attempts to log on to the network (see the arrow 1). The user's
credentials
must be listed in Active Directory on the domain controller.
• If the user is not listed in Active Directory, the user cannot access
any resources on the network.
• If the user is listed in Active Directory, the user can attempt to access
the Enterprise Portal site using a Web browser.
The IIS Web server then receives the request for the Enterprise Portal page
(see
the arrow 2). The Web server verifies whether the user is listed in
Microsoft
Dynamics AX 2009 and in Windows SharePoint Services or Office SharePoint
Server to determine if the user can access the Enterprise Portal site.
• If a user is not listed in both, that user is denied access to the site.
• If the user is listed in both, that user can access the site, and the Web
server sends a request to the AOS server to determine which data and
content should be displayed (if any).
The AOS server then receives the request for Microsoft Dynamics AX 2009 data
(see arrow 3).
• If the user is not listed in any Microsoft Dynamics AX 2009 groups,
the user sees an empty Enterprise Portal page in their Web browser.
• If the user is listed in one or more groups, the Enterprise Portal page
displays content and data defined by the user group permissions.
The Enterprise Portal security components in an extranet deployment can
include
one or more firewall devices and multiple domain controllers, but the
process of
determining page access and the content shown on pages is the same.

Configuring Enterprise Portal Security

Initially, only the administrator who installed Enterprise Portal can access
the
Web site. The process for configuring Enterprise Portal security involves
giving
users access to the Web site and assigning users to Microsoft Dynamics AX
2009
groups so they can view content on the site.
Perform the following procedure to configure Enterprise Portal security:
1. Install Enterprise Portal.
2. Add users to Active Directory. If your organization has Microsoft
Dynamics AX 2009 already installed, users might already be in
Active Directory. If a user is listed in the Users form and the
Enabled option is selected, then they already exist in Active
Directory.
3. Enable the default Enterprise Portal user groups (a subset of the
Microsoft Dynamics AX 2009 user groups) by following the
Enterprise Portal Configuration Wizard.
4. Add users to groups according to each user's role in the company.
5. Assign users access to the site. For more information, see Giving
users access to Enterprise Portal sites.
6. Specify user relations (required for the Shop Floor Control and
Human Resources module sites).

Enterprise Portal Permissions

Microsoft Dynamics AX 2009 uses permissions and security keys to determine
who has access to the data and the Web displayed content using the
Enterprise
Portal.
Security keys are created in the Microsoft Dynamics AX Application Object
Tree
(AOT) and then assigned to various user groups on the User group permissions
form.
Microsoft Dynamics AX partners and developers can create security keys
depending on how the organization wants to control the permissions and
Enterprise Portal Wed displays.
It may be best to assign all the Web content objects and Web menu items on
the
Enterprise Portal to one of the security keys created for Enterprise Portal.
When
the security keys have been created and assigned to the Web menu items and
Web content objects in the AOT, administrators can use the User group
permissions form to set permissions for the Web menu items and Web content
objects.

Set Enterprise Portal Permissions

1. From a Microsoft Dynamics AX client, click Administration >
Setup > Security > User Group Permissions.
2. On the Overview tab, select a user group and then select a domain.
3. Click the Permissions tab. In the Viewing box, select Security (incl
Web).
4. Expand the node for the security key that protects the Web content
object or Web menu item for which you want to set the permissions.
The root entry for each node in the list box is a security key,
followed by child security keys or end AOT elements that are
protected by that security key.
5. Select the check boxes for the Web content object and the Web menu
item for which you want to set permissions.
6. Under Access, select a permissions level. When you select a
permissions level, the selected item shows a check mark to indicate
permissions have been set.
7. Click the Cascade button to make sure all dependent keys are set
and to inherit this permission level to all child tables, forms, and
nodes.
8. Close the form to save changes.

Be sure to assign the same permissions to both the Web content object and
the
Web menu item that points to that content object.

• If access is allowed to the Web menu item only and not to the Web
content object. Then the end-users in this group can view the menu
item where appropriate. But the page it points to does not display the
content from this Web content object.
• If access is allowed to the Web content object only and not to the
Web menu item, then the end users in this group can use this Web
content object in their own Web part pages. However, they do not

This is probably much more than you were looking for, but I hope it answers
your questions to your satisfaction. If not, please supply any additional
questions, and I will do what I can to answer them.

Best regards,
Bill


"SK" <S...@discussions.microsoft.com> wrote in message
news:9B466C2B-076C-44EC...@microsoft.com...

0 new messages