Task for Stakeholders, should we track on Sprint board?

Stories would be a strange thing for anyone to commit to.

If the work is necessary for the Sprint Goal commitment to be met and a Done increment produced, then those stakeholders would also be Developers. They would share in the Scrum commitments being made. That is the truth which is being exposed.

The Developers ought to track the progress of all of the work needed to meet their commitments accordingly.

Since a Sprint board is not something mentioned in the Scrum Guide, this is a decision that your team should make.  The Scrum Guide says that the Scrum Team should make the work that is being done by them transparent. 

The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk.

Transparency enables inspection. Inspection without transparency is misleading and wasteful.

As @Ian stated, if the work that is needed from the stakeholders is required in order to meet the Sprint Goal, then the stakeholders are Developers for the Sprint.  Their work should be made transparent to the rest of the Developers. But this means that they should be included the entire Sprint and all events. Will they attend Sprint Planning?  Would they be willing and able to attend the Daily Scrum?  Will they attend the Sprint Retrospective as a Developer?  Would they be willing to inspect the result of their work and determine if there are ways to improve upon it? 

I understand your basic premise for wanting to track this on your board.  But it is a decision that your team needs to make. It is a procedural decision and is outside of the Scrum framework. 

When we faced a similar situation, we used to create a task - Access approval pending from stakeholders (in our scenario it was access to a data source). The corresponding stories would be set to Blocked status (with the task as the blocker). Until unblocked, the stories remain in the backlog and are not added to the sprint. The task is added in the sprint and is assigned to the Product owner who should help the team get the access from the stakeholder (needless to say the task is not estimated).

The reason for adding it to the sprint is to ensure it is discussed on a daily basis and followups done where required.

I use confluence page to track such tasks and link blocked features/tickets and their impact. This common page provides good transparency to everyone and help team to stay on track.

If you do not use confluence page then you can use any other documentation tool that your team is using.